blogs.ASPItalia.com

Silverlight - Real time audio peak meter

2009-05-31T09:14:00+00:00

In un post precedente ho mostrato di come si può realizzare un misuratore di picchi per l'audio di un MediaElement precalcolandoli con un'applicazione console. Ovviamente questa non è la prassi normale di tutti i lettori normali, dove il calcolo della FFT applicata ai samples avviene in real time, man mano che questi vengono renderizzati sulla periferica audio.

Da Silverlight 2.0 sull'oggetto MediaElement è presente un metodo SetSource che accetta uno Stream oppure un'oggetto MediaStreamSource. Questa classe ha dei metodi che MediaElement chiama, come OpenMediaAsync, GetSampleAsync, SeekAsync per chiederci di aprire la sorgente, di restituirgli gruppi di samples o di posizionarci ad uno specifico timestamp. Con i metodi ReportOpenMediaCompleted, ReportGetSampleCompleted e ReportSeekCompleted non si fa altro che notificargli l'avvenuta operazione e ciclicamente mandargli pacchetti audio/video.

La brutta notizia è che i samples audio e video devono essere compressi (MP4, WMV) e quindi quello che noi possiamo fare è solo fare da tramite per fonire tracce audio e video con i protocolli che vogliamo: RTP, UPNP, streaming custom. Questa è una brutta notizia perché per applicare la FFT occorre avere i samples grezzi, già decodificati. L'oggetto MediaElement non permette di caricare file WAV direttamente, ma il MediaStreamSouce permette invece di passare anche i samples raw, che il file WAV appunto contiene. Sebbene si potrebbe scrivere un decoder MP3, non sono così pazzo da farlo :-), perciò ho scelto di creare un file WavMediaStreamSource che carica tramite WebRequest un file wav e legge l'header per conoscere il numero di canali, i samples al secondo (solitamente 44100) e i bit (8/16). L'implementazione poi non fa altro che rigirare i byte al MediaElement.

Ho portato poi l'algoritmo FFT e di calcolo dei picchi sulla mia libreria Silverlight e diviso il controllo del post precedente in due parti: DataAudioPeakMeter e SamplesAudioPeakMeter. Il primo lavora con il file dat precalcolato e funziona con tutti i formati supportati da SL. Il secondo lavora solo con i file WAV, ma funziona in real time. Entrambi poi fanno uso della BarVisualization per l'animazione.

L'utilizzo è piuttosto semplice:

<MediaElement AutoPlay="False"
              x:Name="media" />

<!-- Visualization -->
<a:SamplesAudioPeakMeter x:Name="sa">
    <a:BarVisualization BarSegmentHeight="4"
        BarMargin="1"
        BarSegmentMargin="1"
        StrokeBrush="Yellow"
        StrokeThickness="1">
        <a:BarVisualization.BarBrush>
            <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">
                <GradientStop Offset="1"
                              Color="Black" />
                <GradientStop Offset="0"
                              Color="Blue" />

            </LinearGradientBrush>
        </a:BarVisualization.BarBrush>
    </a:BarVisualization>
</a:SamplesAudioPeakMeter>

Da codice poi dobbiamo legare la sorgente wav sia al MediaElement che al SamplesAudioPeakMeter:

WavMediaStreamSource source = new WavMediaStreamSource(new Uri("test1.wav", UriKind.RelativeOrAbsolute));
source.Loop = true;

// Binding Source -> Visualization
sa.SetSource(source);
// Binding Source -> MediaElement
media.SetSource(source);

Ed ecco il risultato:

Ovviamente i file wav sono di grandi dimensioni quindi questa tecnica è adatta per file di piccola di dimensione sulla quale fare loop, ma meglio di niente :-). Poi speriamo che magari nella RTM di Silverlight 3.0 ci sia la possibilità di accedere ai samples già decodificati.

Infine le performance: escludendo l'animazione sono rimasto piuttosto colpito. La mia CPU resta su un 2% per calcolare FFT e picchi. Includendo l'animazione si arriva poi ad un 25/30%, ma va considerato che SL tenta sempre di andare al massimo di frame rate per l'esecuzione delle animazioni.
Presto metterò i sorgenti: promesso!

Tags: Silverlight, Silverlight - animazioni, Silverlight 2.0, XAML

Salvare immagini Bitmap con Silverlight 3.0

2009-05-29T17:56:00+00:00

In Silverlight 3.0 è stato aggiunta la possibilità di salvare file in locale attraverso la SaveFileDialog. Per motivi di sicurezza, questa può essere visualizzata solo all'interno di un evento scatenato dall'utente (pressione del pulsante, ecc) mentre attraverso OpenFile è possibile poi aprire uno Stream per la scrittura sulla quale è possibile scrivere qualsiasi cosa.

In una discussione con Marco ci è venuto il dubbio se si poteva salvare immagini in locale, ma purtroppo la cosa non è molto semplice da raggiungere. In SL infatti non ci sono API per effettuare encoding ed decoding di immagini ad eccezione del passare uno Stream da visualizzare. Inoltre con WriteableBitmap è stata aggiunta la possibilità di caricare uno Stream o di renderizzare un UIElement su un'immagine, ma poi non è possibile accedere ai byte. Insomma, se si ha un'immagine già codificata in JPEG/PNG basta semplicemente travasare lo Stream sorgente verso il file locale, altrimenti se si ha solo i byte grezzi dell'immagine occorre scriversi il motore di encoding e di creazione del contenitore.

Per fortuna c'è il buon vecchio file BMP, la cui definizione si può trovare qui, che è abbastanza semplice da creare e a parte dover accodare i byte dell'immagine dal basso verso l'altro, non necessita di algoritmi di compressione. Ovviamente il file risultante è di grandi dimensioni, ma non dev'essere trasportato in rete, ma bensì salvato direttamente in locale. Ho scritto quindi un BitmapEncoder e un BitmapFrame per salvare un'immagine in BMP, lo trovate completo di sorgente qua. L'esempio allegato genera un'immagine con un algoritmo e la mostra anche attraverso un WriteableBitmap.

Purtroppo non serve a tantissimo, perché attualmente la WriteableBitmap non permette di accedere ai pixel e quindi non è possibile salvare screenshot effettuati sugli elementi. Potenzialmente si può creare qualsiasi file, ma ovviamente non è semplice doversi riscrivere librerie di creazione di file, non potendosi appoggiare a oggetti COM.

Tags: Silverlight, XAML, Silverlight 3.0

.NET Framework 4.0 beta 1: Tuple

2009-05-27T04:00:00+00:00

Altro post per un'altra novità del .NET Framework 4.0: le classi Tuple. In pratica sono delle classi generiche con tanti argomenti generici quanti sono le relative proprietà che esse espongono.

Per esempio Tuple<T1, T2> ha una proprietà Item1 di tipo T1 e una proprietà Item2 di tipo T2. Ci vengono molto comode per quelle volte che nei nostri algoritmi, per velocizzare la scrittura del codice (o per pigrizia :-) ), abbiamo bisogno di una classe che faccia da repository dei valori. Inoltre la loro caratteristica è di implementare GetHashCode, Equals e l'interfaccia IComparable, IStructuralEquatable (nuova in .NET 4.0) e IStructuralComparable (nuova in .NET 4.0) in modo che a parità dei valori, due istanze di Tuple diverse risultino uguali. Si comportano quindi come un valore atomico e sono l'ideale per essere utilizzate come chiavi per dictionary o per hash set.

Per capirci quindi:

var t = Tuple.Create<Int32, String>(2, "ciao");
var t2 = Tuple.Create<Int32, String>(2, "ciao");

Console.WriteLine(t.Item2);
Console.WriteLine("Reference equals: {0}", Object.ReferenceEquals(t, t2));
Console.WriteLine("Equals: {0}", t.Equals(t2));

stampa a video:

ciao
Reference equals: False
Equals: True

In effetti c'è una forte somiglianza agli anonymous type sebbene quest'ultimi sono generati dal compilatore e hanno proprietà dal nome che vogliamo. In comune hanno infatti che due istanze diverse, ma con identici valori, risultano uguali se comparati tra loro. Non implementano però IStructuralEquatable, ma non credo che questo sia un problema. Se necessitiamo di lavorare a livello d'interfaccia allora tanto vale restituire una tuple nelle nostre query.

Tags: .NET Framework, .NET Framework 4.0

.NET Framework 4.0 beta1: le classi Lazy<T> e LazyVariable<T>

2009-05-26T16:42:00+00:00

Tra le tante piccole e grandi novità del .NET Framework 4.0 ci sono le classi Lazy<T> e LazyVariable<T>. Il concetto è molto semplice: istanziamo un tipo passando un delegate ad una funzione che restituisce un valore; la prima volta che interroghiamo la proprietà Value, il delegate viene chiamato e il valore persistito per le successive interrogazioni.

Ecco un esempio:

static void Main(string[] args)
{
    Lazy<String> v = new Lazy<String>(GetValue);
    Lazy<String> v2 = v;

    Console.WriteLine(v.Value);
    Console.WriteLine(v.Value);
    Console.WriteLine(v2.Value);
}

private static string GetValue()
{
    Console.WriteLine("GetValue called");
    return "ciao";
}

che stampa a video:

GetValue called
ciao
ciao
ciao

La differenza con LazyVariable è che questa è una struct invece che una classe. Perciò il seguente codice:

static void Main(string[] args)
{
    LazyVariable<String> v = new LazyVariable<String>(GetValue);
    LazyVariable<String> v2 = v;

    Console.WriteLine(v.Value);
    Console.WriteLine(v.Value);
    Console.WriteLine(v2.Value);
}

stampa:

GetValue called
ciao
ciao
GetValue called
ciao

Questo perché quando si assegna v a v2, viene copiata l'intera struttura e non mantenuto un riferimento alla classe come avviene con Lazy.
Entrambe le classi sono inoltre serializzabili e accettano nel costruttore un LazyExecutionMode che dispone di tre valori: NotThreadSafe, EnsureSingleThreadSafeExecution, AllowMultipleThreadSafeExecution. In questo modo possiamo decidere se accedere a Value indicando che solo un thread ci accederà, oppure più thread ci possono accedere e solo una volta il delegate viene eseguito (tramite lock), oppure più thread ci accedono e una o più volte il delegate potrebbe essere eseguito (il default). Mi piacerebbe che implementassero anche la conversione implicita verso T così da non dover interrogare Value, ma forse lo faranno :-)

Tags: .NET Framework, .NET Framework 4.0

Silverlight - Audio peak meter

2009-05-23T16:59:00+00:00

Qualche tempo fa realizzai un controllo per l'analisi dello stream audio e la visualizzazione dei picchi attraverso WPF. Nel tempo libero del tempo libero, da appassionato di DirectShow e di fuffologie mi son chiesto se si poteva fare una cosa simile anche in Silverlight.

Il problema è che in Silverlight non si ha a disposizione DirectShow, non si può usare codice unmanaged ne si può accedere allo stream audio. L'unico oggetto che abbiamo è MediaElement che permette di riprodurre audio e video; nella versione 2.0 c'è la classe MediaStreamSource, ma sebbene non abbia avuto ancora modo di provarla a fondo, permette di accedere allo stream codificato e non quello decodificato, perciò scrivere un decoder mp3 in codice managed non è proprio una passeggiata :-). Per poter applicare FFT e calcolare decibel e picchi dobbiamo infatti avere i byte grezzi, come i file wav.

Siccome per la maggior parte dei casi può bastare un piccolo loop su una canzone ho trovato una facile soluzione: precalcolare. In pratica ho realizzato una console application, interamente managed, che apre un file audio, calcola FFT ecc e salva in un file tutti i byte rappresentativi dei picchi, circa 12 suddivisi per 19 frequenze al secondo.

Una volta che si ha il file audio e il file .dat contenente i picchi, tramite un controllo posso mostrarne i valori. Il controllo AudioMeter ha bisogno del file .dat e del MediaElement sul quale basarsi per mostrare i picchi in funzione della posizione. Ecco il risultato:

Per rendere il più fluido possibile l'animazione intercetto CompositionTarget.Rendering che viene scatenato ad ogni frame dell'applicazione Silverlight che viene renderizzato. Le barre che vanno su e giù sono invece animate da DoubleAnimation.

Devo dire che sono molto soddisfatto del risultato. Anche se il video non rende moltissimo, l'animazione è molto fluida e ben sincronizzata, meglio di quanto avevo fatto con WPF.

Tags: Silverlight, Silverlight - animazioni, Silverlight 2.0, Silverlight 3.0, XAML

.NET Framework 4.0 beta 1: modifiche agli assembly

2009-05-21T20:22:00+00:00

La nuova versione del .NET Framework è un passo molto importante perché oltre a contenere nuove tecnologie o migliorie, si può dire che si dà anche un po' una ripulita e una riorganizzazione visto che il framework era diventato un po' confuso quando dopo la versione 2.0 è stato aggiunta la 3.0 che era basata sempre sulla 2.0, poi allo stesso modo la 3.5 ed infine il service pack 1 che introduceva ancora novità.

Innanzitutto date un occhio al MetadataDiffViewer che l'ho aggiornato alla versione 4.0 così non si perde nessuna novità. Innanzitutto gli assembly sono tutti 4.0 e balzano all'occhio alcuni come System.Web.Routing o System.Web.Abstractions che esistono ancora, ma non contengono classi. Questo perché le loro classi sono state trasferite, come giusto che sia, nell'assembly System.Web. Attraverso i due attributi TypeForwardedToAttribute (presente già dalla versione 2.0) e TypeForwaredFromAttribute si indica a compilatori, CLR e serializzatori vari di redirigere dalla vecchia posizione a quella nuova. In questo modo le applicazioni compilate per il 3.5 SP1 vengono rediretti alla nuova versione 4.0. Le nuove applicazioni invece verranno compilate con la referenza corretta.

Oltre alle novità più importanti ho trovato qualcosa di interessante:

una classe System.AggregateException per raggruppare più eccezioni;
il nuovo namespace System.Collections.Concurrent contenente Queue, Dictionary e Stack già sincronizzate e quindi thread safe. Molto interessante la classe Partitioner per creare enumerazioni che smistano automaticamente il carico di lavoro tra più consumer che ne fanno richiesta;
il nuovo namespace System.Diagnostics.Contracts che contiene in particolare la classe Contract per indicare nel codice verifiche da effettuare in fase di compilazione e/o a runtime all'inizio o alla fine di una funzione (ne parlerò in dettaglio con un altro post);
le classi relative a PLINQ, a ParallelFX, lock ottimizzati come: Task, Parallel, SpinLock, ecc.
le classi Tuple usate da F# però quante volte può servire memorizzare delle informazioni in modo veloce senza creare una classe con proprietà apposite;
il nuovo namespace e assembly System.ComponentModel.Composition che contiene tutta la parte di Managed Extensibility Framework;
in System.Core tante nuove Action e Func :-) Per la parte di expression e delle query LINQ ci sono alcune nuove classi Expression che permettono di fare degli statement: GotoExpression, LoopExpression, SwitchExpression, TryExpression, ecc. Un bellissimo ExpressionVisitor per sfogliare un'espressione: ci voleva!;
i nuovi assembly. System.Web.DataVisualization e System.Windows.Forms.DataVisualization contenente i controlli di charting per web e windows.

E questo è solo l'inizio, che bello che bello, tante cose nuove :-)

Tags: .NET Framework, .NET Framework 3.5, .NET Framework 4.0, ASP.NET, ASP.NET 4.0, LINQ, Visual Studio

.NET Framework 4.0 beta 1: Windows Communication Foundation

2009-05-18T14:00:00+00:00

Vista l'imminente uscita del .NET Framework 4.0 beta 1 vediamo un po' tra le numerose novità, quali sono quelle che riguardano WCF. Nonostate fino ad ora non è stata resa pubblica una build completa si conoscono già le principali nuove caratteristiche.

Si parte dai miglioramenti di prestazioni del DataContractSerializer, motore principale per la serializzazione degli oggetti e un nuovo DataContractResolver che permette di personalizzare la risoluzione dei tipi. La configurazione, punto dolente della prima versione, è stata semplificata. Ora è possibile definire un servizio e/o un behavior con name vuoto e si ottiene una configurazione predefinita per tutti i servizi dell'hosting. I file svc sono poi auto configuranti e ciò significa che viene creato automaticamente un endpoint basandosi sulle configurazioni predefinite dei servizi HTTP.

Sono disponibili poi nuovi binding e nuovi canali tra i quali la possibilità di fare HTTP polling duplex (usato da Silverlight), di esporre un servizio tramite UDP, un nuovo sistema di claim basato su Geneva, nome in codice del nuovo framework per l'autenticazione e gestione dell'identità. WCF 4.0 aderisce alle specifiche Basic Profile 1.2 che garantiscono una migliore interoperabilità tra piattaforme diverse ed implementa inoltre WS-Discovery e il routing. Il primo permette ad un servizio di annunciarsi attraverso endpoint conosciuti che i possibili client possono individuare ed andare a consumare. Con il servizio di routing è invece possibile porre uno strato intermedio che dirotti le richieste verso gli endpoint effettivi a seconda dei carichi od in base a regole XPath applicate sul messaggio.

WCF inoltre si accopia con Windows Workflow Foundation diventando praticamente un solo framework. Questo perché dall'idea di Workflow Services, introdotti con il service pack 1 del .NET Framework 3.5, si è passati ad una forte cooperazione ed integrazione tra le tue tecnologie. Partecipano allo stesso sistema di tracing e di tracking, di gestione degli errori, di transazione e sfruttando WAS e tutti gli strumenti aggiuntivi messi a disposizione per IIS7, raccolti sotto il nome di Dublin, permettono di esporre workflow attraverso servizi e di gestire e monitorare i workflow facilitando moltissimo la creazione di servizi duraturi nel tempo e scalabili.

Maggiori informazioni e le informazioni per il download sono disponibili nel nostro mini-sito dedicato al .NET Framework 4.0.

Tags: .NET Framework 3.0, .NET Framework 4.0, Windows Communication Foundation, Windows Workflow Foundation, .NET Framework

Mostrare la WebCam in Silverlight

2009-05-07T11:00:00+00:00

Nel precedente post ho illustrato la mia idea di dialogo tra Silverlight e la macchina host, ma ora vediamo un caso pratico.

Prima di tutto ho preparato un'applicazione Windows senza finestre, ma che rimane sulla system tray mettendosi in ascolto come policy server e su un'altra porta in attesa di connessioni. Questo "server" alla prima connessione avvia un filtro DirectShow che prende l'immagine della WebCam, prende ogni frame attraverso un Sample Grabber e lo comprime in Jpeg ad una qualità non troppo impegnativa. I bytes risultati vengono inviati al client preceduti da 8 byte che indicano la dimensione dell'immagine e quindi dei bytes che il client si deve aspettare. Ciò che ottengo quindi è di fatto un Motion Jpeg pià alcuni controlli che il server fa per saltare frame qualora il client sia in ritardo a ricevere i fotogrammi.

Il client Silverlight invece avvia la connessione e in modo ciclico legge nel buffer i primi 8 byte per conoscere la dimensione dell'immagine. Carica i restanti byte con i quale crea un MemoryStream che dà poi in pasto al metodo BitmapImage.SetSource. Quest'ultimo carica l'immagine che viene poi associata ad un oggetto Image di Silverlight. In pratica quindi, vi è un flusso continuo di bytes di immagini compresse che vengono poi ricostruite per formare i fotogrammi dell'immagine con il quale poi ci si può sbizzarrire come si vuole.

Ho creato poi un deployment con ClickOnce per avviare il server automaticamente e dei byte "magici" che manda il client per chiudere il server. Questo il risultato finale:

Silverlight con questa tecnica si comporta bene e l'uso della CPU è non è intenso, garantendo sempre un flusso fluido dell'immagine.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Silverlight, Silverlight 2.0, Windows 7, Windows Client, XAML

Comunicazione TCP tra Silverlight e WPF

2009-05-06T21:46:00+00:00

Negli ultimi giorni mi sono incuriosito su come risolvere un'esigenza che potrebbe capitarmi in futuro: la comunicazione tra Silverlight e una application WPF/WinForms.
Silverlight ha potenzialità limitate e potrebbe utile usare un'applicazione classica locale che non ha limiti in termini di funzionalità.

Per questo scopo in Silverlight fortunatamente hanno lasciato la classe Socket che, sebbene il suo utilizzo differisce dal .NET Framework, permette di connettersi ad un end point e dialogare direttamente con i bytes, permettendo ampio margine di movimento e consentendo di implementare protocolli standard o custom.

Con questo post non è mio intento spiegare in dettaglio come si usa il socket, ma illustrare come vedo io una possibile implementazione e una collaborazione tra un'applicazione locale e una in Silverlight. Innanzitutto bisogna tenere conto che Silverlight può connettersi solo al range di porte 4502-4534, per ovvi motivi di sicurezza: evitare che un'applicazione possa essere strumento di attacchi DoS o Reverse tunnel. Inoltre sia che ci si connetta al host di origine sia ad un host esterno (cross site), è necessario che il server sia in ascolto anche sulla porta 943 (fissa) che su richiesta deve restituire il file clientAccessPolicy.xml che già conosciamo per le richieste HTTP, ma che viene validato anche per le richieste socket.
A questo indirizzo troviamo un esempio di classe PolicyServer per implementare questa logica di validazione, qualora un client Silverlight la richieda.

Con l'esempio indicato possiamo anche vedere come con il pattern Begin/End possiamo accettare nuove connessioni, inviare e ricevere bytes e creare di fatto un nostro protocollo di dialogo. Infatti l'idea è che una volta avviata l'applicazione Silverlight, qualora serva, facciamo partire quella locale che si mette in ascolto e con la quale poi si instaura un dialogo per chiedere informazioni al server o viceversa.

Per far partire il server viene in aiuto ClickOnce che grazie al sua capacità di installare un'applicazione al volo, la fa anche avviare. Basta navigare aprendo una popup al file .application e l'applicazione viene installata, previa conferma, e poi avviata.

private void StartButton_Click(object sender, RoutedEventArgs e)
{
    // Avvio l'applicazione con ClickOnce
    Uri appUri = new Uri("http://test.aspitalia.com:50658/setup/WebCamStreaming.application");
    HtmlPage.PopupWindow(appUri, "_blank", new HtmlPopupWindowOptions());

    // Avvia la comunicazione TCP
    client.ConnectAsync();
}

Attraverso poi un Mutex si può impedire che più istanze partano, lasciando sempre un solo server attivo. Qualora poi non serva più, possiamo sfruttare sempre la connessione tcp per inviare un segnale di chiusura dell'applicazione.

Nel prossimo post mostrerò un esempio completo di tutto questo ambaradam di cui darò i sorgenti.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Silverlight, Silverlight 2.0, XAML

Dettagli sul metodo SelectDTO

2009-04-26T12:19:00+00:00

Vorrei aggiungere alcuni dettagli sul mio post riguardo LINQ to Reflection ed in particolare sull'extension method SelectDTO.

Quello che il metodo fa è creare un expression identica a quello che faremmo scrivendo a mano il mapping. Prendiamo per esempio il classico Northwind e una classe di nome CustomerDTO:

public class CustomerDTO
{
    public string ContactName { get; set; }
    public string ContactTitle { get; set; }
    
    public override string ToString() { 
        return String.Format("{0} {1}", ContactTitle, ContactName);
    }
}

Per caricare la lista dei customer e creare istanze del nostro DTO dovremmo fare:

using (NorthwindEntities ne = new NorthwindEntities()) {
    IList<customerdto> l = ne.Customers.Select(c => new CustomerDTO
    {
        ContactName = c.ContactName,
        ContactTitle = c.ContactTitle
    }).ToList();
}

Usando il mio extension method invece:

using (NorthwindEntities ne = new NorthwindEntities())
{
    IList<CustomerDTO> l = ne.Customers.SelectDTO<Customers, CustomerDTO>().ToList();
}

Ciò che si produce è la medesima Expression del metodo classico, perciò LINQ to Entities la tradurrà nel medesimo modo, scaricando solo le colonne che ci interessano:

SELECT 
1 AS [C1], 
[Extent1].[ContactName] AS [ContactName], 
[Extent1].[ContactTitle] AS [ContactTitle]
FROM [dbo].[Customers] AS [Extent1]

Quello che si paga è solo il prezzo di iniziale di reflection per l'analisi delle proprietà in comune tra le due classi. Ovviamente questo è un inizio, va valutato perché comunque ha un costo, ha il vincolo di dover chiamare le proprietà che si vogliono copiare con lo stesso nome, ma lo si può estendere.

Tags: .NET Framework, .NET Framework 3.5, ADO.NET Entity Framework, LINQ, LINQ to Entities, LINQ to SQL

Parallelizzare in Silverlight 2.0

2009-04-21T05:27:00+00:00

Durante lo sviluppo di MetadataDiffViewer ho dovuto fare i conti con la grande quantità di informazioni da dover processare e dover trovare un modo di rendere l'interfaccia la più utilizzabile possibile. Per prima cosa ho optato per preparare una struttura di assembly/module/type/member tutta in lazy loading, in questo modo solo nell'espandere un assembly vengono caricati i moduli, solo espandendo un modulo vengono caricati i tipi ecc. LINQ a questo scopo è fantastico perché lavorando con IEnumerable si può parserizzare, incrociare, ordinare, ma elaborare il tutto solo quando viene effettivamente consumato.

Questo comporta però un difetto perché non mi consente di mostrare preventivamente quali assembly sono cambiati. Ho optato quindi per eseguire in un thread in background e ciclare per la struttura ad oggetti; appena trova un elemento cambiato, l'intero assembly è cambiato e perciò evito di proseguire. Questa operazione era comunque lunga e la cosa meno piacevole era vedere la cpu che lavorava solo al 50%, essendo un dual core.

Mi son scritto quindi un piccolo extension method, specifico per la mia esigenza, per parallelizzare un'operazione basata su sorgenti LINQ. Il primo problema è determinare quanti core abbiamo a disposizione, ma non potendo accedere all'OS ho ripiegato sul fatto che il thread pool in SL 2.0 ha 250 thread per core e questo numero non si può cambiare. Perciò ho creato una semplice proprietà:

private const int DefaultThreadsPerCpu = 250;

public static int CpuNumber {
    get {
        int wt; int cpt;
        ThreadPool.GetMaxThreads(out wt, out cpt);
        return Math.Max(1, wt / DefaultThreadsPerCpu);
    }
}

L'extension method che ho poi definito accetta una sorgente dati sul quale ciclare e un delegate ad una funzione che elabora ogni item ed eventualmente restituisce un risultato:

public static IEnumerable<tresult> ForEach<IEnumerable<T>, TItem, TResult>
                                   (this IEnumerable<T> source, Func<TItem, TResult> process)
{
{

Per prima cosa ho ripartito la sorgente in n parti, quante sono le cpu, incrociando gli item. Ad esempio su due core al primo vanno l'item 1,3,5.., al secondo vanno 2,4,6.

int cpuNumber = CpuNumber;

// Elementi da processare per ogni cpu
IEnumerable<TItem>[] items = new IEnumerable<TItem>[cpuNumber];
// Semafori di notifica per ogni cpu
ManualResetEvent[] events = new ManualResetEvent[cpuNumber];
// Risultati ottenuti per ogni cpu
IList<TResult>[] results = new IList<TResult>[cpuNumber];

int itemsPerCpu = (int)Math.Ceiling(source.Count() / (double)cpuNumber);

for (int x = 0; x < items.Length; x++)
{
    items[x] = new TItem[itemsPerCpu];
    int cpu = x;
    // Ripartizione incrociata
    items[x] = source.Where((item, index) => (index + cpu) % cpuNumber == 0);
}

L'uso della variabile interna cpu che semplicemente ricopia x è fondamentale perché all'atto del consumo di items[] x sarebbe sempre all'ultimo valore. Usando LINQ occorre infatti ricordarsi che l'elaborazione avviene a posteriori, a meno non si chiami un ToList/ToArray.

A questo punto avvio i thread e aspetto tramite un WaitHandle che questi abbiamo finito di lavorare:

for (int x = 0; x < items.Length; x++)
{
    // Semaforo di notifica al thread che ha lanciato ForEach
    events[x] = new ManualResetEvent(false);
    results[x] = new List<TResult>(itemsPerCpu);
    Thread t = new Thread(delegate(object i)
    {
        int index = (int)i;

        foreach (TItem item in items[index])
            results[index].Add(process(item));

        events[index].Set();
    });
    t.Start(x);
}

WaitHandle.WaitAll(events);

I risultati sono un List che poi vengono restituiti, in questo caso non nello stesso ordine della sorgente. Tutto questo per la mia esigenza, ma le variabili possono essere tante, in funzione della sorgente (può non essere possibile dividere il carico in quel modo), o del risultato (certi risultati dipendono dai risultati degli altri thread), ma è un inizio. L'uso poi è molto semplice:

var r = from n in Enumerable.Range(1, 1000)
     select "Ciao " + n;
int l = r.ForEach(s => s.Length).Sum();

Tags: .NET Framework 3.5, LINQ, Silverlight, Silverlight 2.0, XAML

LINQ to Reflection - Parte tre

2009-04-20T05:17:00+00:00

Ho avuto un po' di tempo per fare alcune aggiunte alla libreria che ora è disponibile nel lab.

Ho aggiunto una classe DTOCopy<Tsource,TTarget> che mi permette di memorizzare attraverso un membro statico le proprietà che hanno in comune due classi. L'uso di una classe generica mi permette di avere un meccanismo automatico di cache in funzione delle classi che fanno da source e da target. Lo scopo è creare un extension method CopyTo per copiare i valori da una classe ad un'altra, utile nei DTO:

public class ProductDTO{    public ProductDTO()    {    }    public ProductDTO(Product source)    {        // Copia solo le proprietà che hanno in comune        source.CopyTo(this);    }    public string Description { get; set; }}

Un secondo extension method invece permette di creare un expression linq per un object initializer di una classe DTO. Siccome mi capita spesso di avere un'entità LINQ to SQL o LINQ to Entities e nell'espressione LINQ voglio avere come risultato una classe DTO, mi son fatto un extension method che mi evita di elencare tutte le proprietà da travasare:

// Espressione LINQ per DTOIQueryable<Product,ProductDTO> products = new Product[] { new Product { Description = "ppp" } }.AsQueryable();IEnumerable<ProductDTO> productsDTO = products.SelectDTO<Product,ProductDTO>();

Decisamente comodo :-)

Tags: .NET Framework, .NET Framework 3.5, .NET Framework 4.0, LINQ

Silverlight: performance dell'isolated storage

2009-04-16T17:03:00+00:00

Durante lo sviluppo del MetadataDiffViewer ho dovuto ricorrere all'uso dell'Isolated Storage per salvare i metadati in locale e poterli prelevare da disco invece che da remoto. Ho notato però che le performance, rispetto allo scaricare da un webserver in locale, erano peggiori ed era imputabile a:

la chiamata a IsolatedStorageFile.GetUserStoreForApplication/Site: è molto costosa, aprendo lo storage una sola volta, dall'inizio alla fine ho guadagnato un 40% di performance;
la lettura dello stream attraverso IsolatedStorageFileStream: è un più lenta rispetto ad uno stream in memoria nelle operazioni di accesso randomico. Questo è ovvio visto che va su disco, ma non pensavo così tanto. Precaricando il tutto in un MemoryStream e parserizzando poi l'XML con XDocument.Load in un'attività, ho guadagnato 3 secondi su 14 e non è poco.

Insomma, occhio a come lo usate.

Tags: Silverlight, Silverlight 2.0, Silverlight 3.0, XAML

MetadataDiffViewer: differenze tra i framework

2009-04-15T16:56:00+00:00

MetadataDiffViewer è un'applicazione in Silverlight che mostra le differenze in termini di assembly/module/type/member tra una versione del .NET Framework e l'altra. Semplicemente mostra alcune informazioni precalcolate per conoscere nel dettaglio cosa c'è di nuovo in una nuova versione.

Ecco uno screenshot:

Lo potete provare qua.

Non so voi, ma mi dà fastidio essermi perso un nuovo membro. Con questo tool non ci sono più scuse :-)

Come funziona?

Ho innanzitutto creato un addin per Reflector così da poter esportare i metadati pubblici degli assembly. La reflection classica non permette di caricare più versione del framework e in un'ottica continua nel tempo ho deciso di esportare i metadati e tenerli sempre pronti. Una console application poi li compara e crea un file di differenze. I metadati e le differenze sono file XML di discreta dimensione perciò, per non riscaricare tutte le informazioni ogni volta, ho deciso di salvare le informazioni nell'isolated storage. Per tenersi il tutto servono circa 60MB (tranquilli, sono zippati quando si scaricano).

I framework comparati che sono a disposizione sono:

Silverlight 2.0 -> Silverlight 3.0
.NET Framework 1.1 -> .NET Framework 2.0
.NET Framework 2.0 -> .NET Framework 3.5

Se avete problemi o consigli, scrivetemi.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Silverlight, Silverlight 2.0, Silverlight 3.0, XAML

Documentazione MSDN e versioni del .NET Framework

2009-04-15T13:23:00+00:00

In questo post qualcosa di poco tecnologico, ma che mi segno per me e magari anche voi, per trovare velocemente la documentazione delle classi. Le versioni del framework sono infatti ormai tante: .NET Framework 1.0 - 1.1 - 2.0 - 3.5 e Silverlight 2.0 - 3.0.

Cercando nei motori di ricerca per esempio system.string probabilmente troveremo il link a:

http://msdn.microsoft.com/en-us/library/system.string.aspx

che ci porta alla documentazione riferita alla versione attuale: la 3.5.

Mettendo tra parentesi dopo system.string la versione possiamo però distinguere e forzatamente guardare uno specifico framework. Per Silverlight 3.0 per esempio è:

http://msdn.microsoft.com/en-us/library/system.string(vs.96).aspx

Ecco un riassunto delle versioni:

vs.71: 1.1
vs.80: 2.0
vs.85: 3.0
vs.90: 3.5
vs.95: SL 2.0
vs.96: SL 3.0

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Silverlight, Silverlight 2.0, Silverlight 3.0, XAML