Second Life e i misteri del BackgroundYieldTime (ovvero, migliorare il multitasking)

Tutti i client per Second Life sono avidi di risorse. Se va bene, stando seduti in qualche posto facendo nulla porta via 350 mega di ram e 30/40% di CPU. È facile da verificare, basta dare un’occhiata a Gestione attività di Windows ((Ctrl+Maius+Esc in Win 7).

Si apre un altro programma e sboink, il sistema appare bloccato, ovviamente. È una situazione molto comune, e il problema è che anche passando ad un altra finestra l’occupazione di risorse rimane elevata. Se vi capita spesso di usare Second Life in combinazione a qualche altro programma, sapete bene di cosa sto parlando.

Imprudence sta usando il 50% della CPU per fare... niente

Però, un parametro di Debug Settings permette di migliorare questo comportamento: BackgroundYieldTime serve a determinare con che intervallo in millisecondi generare nuovi frame quando il client non è in primo piano.

Il valore di default è 40, provate a impostare BackgroundYieldTime a 500 e notate la differenza in Gestione attività: dal 55% di CPU al 10% nella stessa identica situazione non è male (ed è attivo anche lo streaming audio)! E d’altra parte, a che vi serve avere un framerate di 80 fps se non state facendo nulla in SL? Perché sì, SL si sta ciucciando anche la vostra GPU

Ovviamente la vostra CPU e gli altri programmi in esecuzione ringrazieranno sentitamente.

con il nuovo parametro la situazione migliora decisamente

Annunci

Moduli PDF: validare i campi obbligatori, che passione

In moduli complessi è necessario prevedere un meccanismo di validazione degli inserimenti dati effettuati dall’utente nei campi obbligatori.

LiveCycle Designer e Acrobat per i moduli prevedono una gestione di questa problematica via JavaScript o FormCalc, con una abbastanza complessa procedura di validazione di pattern non sempre chiara.

Però, se non è necessario effettuare una vera e propria convalida del pattern di validazione a partire da LiveCycle Designer 8.02 in sù è disponibile un semplice check di compilazione che richiede soltanto l’inserimento di una riga nel codice XML del modulo.

  1. Create il campo di testo obbligatorio nel modulo con i normali strumenti di LiveCycle, definendone se necessario la lunghezza in caratteri e nella scheda Valore selezionate la voce Inserito dall’utente – Richiesto nell’elenco a discesa Tipo per rendere la compilazione del campo obbligatoria.
  2. Passate alla vista XML del modulo selezionando Visualizza > Sorgente XML.
  3. Individuate nel codice le righe
    <present>
    <!-- [0..n] -->
  4. All’interno dell’elemento <present> potete aggiungere le seguenti condizioni di <validate>:
    prePrint
    preSave
    preSubmit
    preExecute

    Anche combinate.
  5. Per esempio, per fare in modo che venga effettuata una verifica sui campi obbligatori al momento del salvataggio, aggiungete
    <validate>preSave</validate>

Il codice risultante sarà:

<config xmlns="http://www.xfa.org/schema/xci/1.0/">
<agent name="designer">
...
</agent>
<present>
<!-- [0..n] -->
<validate>preSave</validate>

Le condizioni possono essere combinate, se desiderate che il check venga eseguito prima della stampa aggiungete al modulo un pulsante Print, e così via.

Il codice

<validate>prePrint preSubmit</validate>

Produrrà una azione di verifica al momento della stampa o dell’invio per e-mail del modulo.

Nell’esempio, al momento del salvataggio del modulo compilato verrà eseguito un controllo e se il campo obbligatorio non è stato compilato comparirà un messaggio di errore e nel modulo i campi non corretti saranno evidenziati in rosso.
Con LiveCycle Designer ES2 (distribuito con Acrobat X), è possibile personalizzare la modalità di presentazione degli errori, selezionando in una lista l’opzione preferita:

  • Show Every Message In Its Own Message Box One After The Other.
  • Combine The Messages Of All The Failed Fields Into One Message Box.
  • Show the First Failed Field’s Message And Suppress Any Other Messages

Second Life e i misteri del Maximum Bandwidth

Sull’opzione Maximum Bandwidth presente nel pannello Network della finestra di dialogo Preferences dei vari client di Second Life mi è capitato di sentirne di tutti i colori.

“Mettilo al massimo, così sarai più veloce”. “No, al minimo, così andrai più veloce”. “Lascialo coi valori di default, sarai velocissimo”. E chi più ne ha più ne metta. Quasi a nessuno viene in mente che un valore troppo grande provoca rallentamenti quanto uno troppo piccolo.

È una opzione un po’ misteriosa, e sembra che i “tweakers professionisti” vadano un po’ a caso. Che cos’è il maximum bandwith e cosa fa questo slider?

Per prima cosa, è necessario comprendere che Second Life è un sistema client/server: il vostro client preleva i dati da una serie di server nei data center Linden.

Il grosso delle comunicazioni fra il vostro client e i server va direttamente a un singolo server, quello che esegue la sim dove siete in questo momento, anche se la versione 2 del viewer cambia questo paradigma permettendo al viewer di scaricare direttamente le texture dall’asset store.

In un sistema client/server, il client (il viewer) pone una serie di richieste al server, che invia delle risposte di conseguenza. Il viewer gestisce il traffico e “ricrea il mondo” di Second Life, ma l’opzione Maximum Bandwidth non controlla tutto questo traffico. Proviamo a capire quali sono i pacchetti gestiti da questa opzione.

Geometry data

Questa geometria descrive la forma dei prim e degli avatar. Provate a selezionare Advanced > Rendering > Wireframe nel vostro client [1. faccio riferimento a Imprudence Experimental, ma questa opzione è presente in tutti i client.].

Vista in wireframe in Second Life

Vista in wireframe in Second Life

Quella che vedete è la geometria degli oggetti che costituiscono il luogo in cui siete, e la vostra scheda grafica crea il rendering 3D della scena da questi dati geometrici (coordinate 3D degli spigoli dei triangoli nella mesh) e mostra questa vista. Questa è una delle cose della scheda grafica che determina le performance in un mondo 3D. Semplicemente alcune schede grafiche sono più veloci di altre nel convertire i dati delle geometrie in forme. Spesso si misura questa performance in termini di quanti vertici per secondo possono essere renderizzati.

Texture Data

Un altro lavoro svolto dalla vostra scheda grafica è aggiungere le texture (immagini) alla scena ed “avvolgerle” sugli oggetti. È la normale visualizzazione in Second Life.

Control Data

I control data sono tutte le informazioni inviate in entrambi i sensi che riguardano posizione e movimento degli avatar, oggetti, luci e posizione della vostra telecamera. Questi dati vengono scambiati ogni volta che vi spostate o muovete la vostra telecamera o qualche altro avatar nella scena si sposta, o quando uno script provoca un movimento nella scena.

Elementi multimediali e voice non sono controllati da Maximum Bandwidth. Questi elementi sono gestiti da un sub-sistema completamente diverso dei client.

Che cosa fa lo slider Maximum Bandwidth?

Ci sono tante teorie al proposito, e qui ci si rifà a quelle di Joelfoner.com, che mi sembrano ragionevoli.

Dopo molte sperimentazioni e indagini, le certezze sono queste: quando utilizzate Second Life, impartite istruzioni al viewer in vari modi utilizzando tastiera, mouse, altri dispositivi di puntamento, dicendo al viewer cosa fare quando accade qualcosa. Queste azioni si riflettono in richieste che vengono inviate al (ai) server.

Alcune di queste richieste sono gestite da Maximum Bandwidth, altre no (approfondimenti nell’articolo sopra citato).

Lo scambio di dati è gestito in modo piuttosto sofisticato: l’impostazione attuale di Maximum Bandwidth viene inviata al simulatore, e indica quale si supponga che sia la banda massima di cui il viewer dispone per scambiare i dati. Non è un valore che viene misurato, il simulatore “si fida” di quello che dichiarate.

Il simulatore quindi assume che voi disponiate di quella banda, e gestisce lo stream dei dati verso il vostro client di conseguenza, con un flusso di dimensioni all’incirca pari o minore del valore indicato in Maximum Bandwidth. Se il viewer inizia a evidenziare pacchetti persi, il simulatore rallenterà per evitare di affogare il vostro client (il viewer) con i dati. Ma non è una scienza esatta, potrebbe iniziare a inviarne decisamente pochi.

A quanto andrebbe impostato Maximum Bandwidth?

Dipende dalla vostra connessione, ovviamente. Un metodo per stabilire con una qualche certezza questa dimensione, può essere misurare fisicamente la vostra banda con uno strumento come SpeedTest.net o analoghi. In genere, il numero che leggerete in “Download Speed” dopo il test è quello che potreste indicare come valore di Maximum bandwidth. Certo, a patto che non utilizziate la connessione contemporaneamente con altri programmi come browser, Skype, scambio di file, voice, audio e video, ecc. ecc.

Questo è particolarmente importante qualora disponiate di una connessione lenta o usiate una rete wi-fi.

Facendo i vostri test, ricordate che l’impostazione di un valore troppo alto rallenterà la vostra esperienza, provocando lag e malfunzionamenti poiché il numero di pacchetti persi diventerà rapidamente ingestibile (per controllare, selezionate Help > About > il vostro client. Fra le varie informazioni presenti c’è anche Packets Lost, ovvero la quantità di pacchetti persi).

È certamente di aiuto tenere aperto il pannello Statistic Bar, che trovate nel menu View, come spiegato in questo video (in cui però Torley ha un po’ sbragato secondo me, come qualcuno gli fa notare nei commenti).

Inoltre, provate ad usare anche WinMTR, una utility che vi permette di monitorare la connessione fra voi e il server su cui siete (potete conoscere l’indirizzo del vostro host leggendo le informazioni nel pannello About (menu Help). La situazione ideale prevede che la colonna Loss % contenga solo valori a 0.

Monitorare la connessione con WinMTR

Come già detto, ci sono diversi tipi di traffico gestiti dal viewer. Il viewer fa richieste ai server per ottenere dati, e l’opzione Maximum Bandwidth indica al server le dimensioni del flusso di dati gestibile dal vostro viewer per evitare di sovraccaricarlo. Questa impostazione determina grossolanamente la velocità a cui il server invia i dati al viewer, e così un valore troppo basso riduce le prestazioni del viewer stesso senza motivo, però uno troppo alto provoca lo stesso lag, a causa dei pacchetti persi [2. Alcuni consigli ed altri.]. Maximum Bandwidth dovrebbe essere inpostato al massimo possibile prima che il viewer inizi nuovamente a rallentare e a perdere pacchetti, o prima che i servizi multimediali o il voice si interrompano a causa di una bassa velocità di connessione.

Un altro aspetto da considerare è quello relativo alle vostre impostazioni TCP/IP sul sistema operativo e sul computer utilizzato. Prima di “dare la colpa” alla connessione o a Second Life, provate a usare qualche strumento come TCP Optimizer o leggete attentamente il post “Windows 7, Vista, 2008 Tweaks“.

È uno sforzo abbastanza inutile litigare col client se la vostra connessione non è ottimale, no?

PDF accessibili: il problema della verifica di accessibilità

pdf accessibili: il pdf accessibility checker

Con “PDF accessibile” si è bollato un po’ di tutto. Come tentato di spiegare molte volte in diversi post, uno dei problemi dell’accessibilità dei file PDF consiste (consisteva?) nell’impossibilità di eseguire una verifica di accessibilità almeno tecnica ed oggettiva sul file stesso, poiché non c’era modo di eseguirla se non disponendo di Acrobat Pro, programma abbastanza costoso di per sé.
Qualcosa è cambiato, e sono contento di presentare il PDF Accessibility Checker di Access for All, una fondazione svizzera.

Un tool gratuito ma non per questo approssimativo, più analitico del validator di Acrobat Pro stesso nella produzione del report: come ben spiegato nel manuale d’uso, l’analisi svolta approfondisce aspetti determinanti come il corretto ordine di lettura, la presenza di testi alternativi, la congruenza della struttura dei titoli, l’ordine di lettura navigando con la tastiera, la disponibilità dell’attributo title, la definizione della lingua del documento per un totale di 14 criteri di verifica:

  1. Document is marked as tagged
  2. Document Title available
  3. Document Language defined
  4. Accessible Security Settings
  5. Tab follows Tag-Structure
  6. Consistent Heading Structure
  7. Bookmarks available
  8. Accessible Font Encodings
  9. Content completely tagged
  10. Logical Reading Order
  11. Alternative Text available
  12. Correct Syntax of Tags / Rolls
  13. Sufficient contrast for Text
  14. Spaces existent

Insomma, che dire. BRAVI! Un grosso passo avanti. Ora aspettiamo l’editor di PDF ed è fatta.

Second Life: Dolphin Viewer, un outsider fra i viewer 2.0?

Zitto zitto quatto quatto, mentre i principali sviluppatori di viewer alternativi sembrano dibattersi nello stallo fra beta e annunci a tempo indeterminato, il Dolphin Viewer è sorprendente.

Disponibile sia in versione 1.5 che 2.5, questo viewer risulta abbastanza sconosciuto e quindi leggendone le caratteristiche si resta un po’ sorpresi. La 1.5 è allineata ai viewer che vanno per la maggiore, mentre la 2.5 è di molto avanzata rispetto agli altri contendenti.

Però leggendo un po’ il sito si capisce anche perché: i viewer sono basati su quel Henri Beauchamp’s Cool VL Viewer che per primo ha introdotto caratteristiche così di moda come l’intrusivo radar (quanti sono gli utenti di Phoenix che usano questo viewer soltanto per spiare con il radar, pensando che sia una invenzione del team dello “sfortunato” Emerald?) o l’utilissimo doppio clic teleport, e un vasto elenco di opzioni che hanno fatto la fortuna di numerosi “copioni”.

Comunque, fra tutte le nuove opzioni del Dolphin Viewer 2.5 mi è piaciuta quella che aggiunge al riquadro Snapshot la possibilità di caricare direttamente le foto su Flickr, e ok mi ha fatto ridere il radar arrivato ormai a 2.048 metri di estensione, alè (nel viewer 2, non nell’1). Interessante anche l’interfaccia a Growl (funzionante, non come in altri viewer), le modifiche nell’interfaccia, la disponibilità del Qarl Fizz Alignement tool, il media filter, e così via. E piccole finezze come la chat range evidenziata nella minimap.

Insomma, da tenere d’occhio.

l'uploader Flickr nella finestra Snapshot

Markup e spam

Ovvero: mai dare nulla per scontato.

Tempo fa, leggevo sulle liste di discussione del W3C un messaggio che faceva così:

While in the middle of compiling an e-mail message, a screen opened and an ad for a mortgage company appeared. A few minutes later, the same thing happened again. When I went to the site indicated by this obnoxious spammer and checked the “View Source” option to try to find someone I could complain to, there was this reference in the opening line: “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd” The company is called Preferred Mortgage and its practices are obnoxiously intrusive. I trust you have nothing to do with them.

Per me si trattava evidentemente di uno scherzo, ma molto seriamente Jan Jacobs rispondeva:

Hello, You are correct; this has nothing to do with us beyond the fact that they are using HTML. Please see this FAQ for more information: http://www.w3.org/Help/Webmaster.html#spam _ Ian

In effetti, fra le FAQ si spiega anche che il W3C no, non è uno spammer e che la presenza di quella stringa nel codice indica esclusivamente che la pagina è fatta in HTML.

Mi sembra pazzesco, ma evidentemente non è così per molte persone. Non so bene cosa, ma c’è qualcosa su cui riflettere in questo. E mi chiedo: per quale motivo uno va a vedere in View Source il codice se non ha la minima idea di quello che sta vedendo? Mah.

EPUB 3, che novità?

Stanlio piange pensando a epub 3Il formato Epub è diventato velocemente uno standard per i libri elettronici, è quindi piuttosto interessante capire quali siano le novità della nuova annunciata release Epub 3.0 (per la metà del 2011, si dice).

Epub 3 è basato su quattro specifiche:

  • EPUB Publications 3.0 [Publications30], che definisce il livello semantico e i requisiti di conformità di EPUB Publication.
  • EPUB Content Documents 3.0 [ContentDocs30], definisce i profili di XHTML, SVG e CSS utilizzabili nel contesto di EPUB Publication.
  • EPUB Open Container Format (OCF) 3.0 [OCF3], definisce formato del file e modello di processing per incapsulare un set di risorse correlate in un singolo file  (ZIP) EPUB Container.
  • EPUB Media Overlays 3.0 [MediaOverlays30], definisce formato e modello di processing per la sincronizzazione di testo e audio.

Le nuove specifiche aumentano in modo significativo le capacità del formato di gestire una più ampia tipologia di pubblicazioni, layout complessi, rich media e interazione e miglior supporto alla tipografia. EPUB 3 potrà essere utilizzato per libri, riviste, manuali tecnici, professionali e scientifici (forse).
In breve, un bel passo avanti rispetto alla precedente versione, adatta a pubblicazioni dalla struttura piuttosto semplice ma evidentemente in crisi davanti a pubblicazioni appena complesse.
Le differenze col precedente Epub 2.1 sono molte, e d’altra parte visti gli obiettivi non potrebbe essere diversamente.

Dal punto di vista markup, si passa a XHTML 5 (che è una cosa diversa da HTML5, come si legge in molti articoli ma pazienza), e la presentazione viene affidata a CSS3. È stato aggiunto il supporto a MathML e mi ha molto incuriosito un meccanismo chiamato “Semantic inflection” e il suo attributo axis.

Anche TTS, scripting e trigger sono delle novità, e audio e video benvenuti.

Una certa attenzione sembra riservata anche all’accessibilità, per la struttura dei file approfittando della maggiore precisione semantica di HTML 5  (per esempio, tramite gli elementi section, nav, aside) e attraverso l’introduzione dell’attributo epub:type [ContentDocs30], che fa lo stesso lavoro di role del W3C. Miglioramenti anche al meccanismo di navigazione, layout dinamici che si adattano all’utente e non viceversa, text-to-speech, meccanismi di fallback per chi avesse bisogno di versioni in formati diversi, insomma tante cose interessanti.

Una vera nuova versione per Epub, e piuttosto elaborata. Certo, quando gli user agent la supporteranno e HTML5/CSS3 saranno uno standard[1. Per avere dei riferimenti, HTML 5 andrà in Last Call questo maggio e la milestone per il rilascio è fissata al 2014, per CSS3 nessuna notizia, solo qualche aggiornamento.],  ma questa è un’altra storia. E purtroppo la conosciamo bene.

Qui da noi c’è chi esulta non si capisce bene perché, e c’è anche chi più pragmaticamente e autorevolmente (Strahinja Markovic, lo sviluppatore di Sigil) avvisa “Ma che state dicendo…”.  Tenderei a dargli ragione.

“Publishers: “HTML5 BOOKS? MOAR! LOOK MA IM IN TEH FUTUAR! We’re totally not going to go extinct now!”