CSS Zibaldone

Gecko: sguardo d'insieme

Chris Waterson

<waterson@netscape.com>

10 giugno 2002

Sguardo d'insieme

• Flusso di dati di base
• Strutture di dati fondamentali
• Analisi dettagliata
• Incrementalismo
• Futuri talk tecnici
• Q&A

Flusso di dati di base

• Il documento sorgente arriva attraverso le API di rete
• "Spinto" in modo incrementale attraverso il motore di layout a thread singolo
  • Parsing, calcolo dello stile, resa; ripetere
  • I CSS usati per rendere tutto il contenuto
• Il contenuto in teoria separato dalla "presentazione"

Flusso di dati di base

Flusso di dati di base

Flusso di dati di base

Flusso di dati di base

Flusso di dati di base

Flusso di dati di base

Strutture di dati fondamentali

• Nodo del contenuto
  • Elementi, attributi, foglie
  • DOM
• Frame
  • Formattazione primitiva rettangolare
  • Informazioni geometriche
  • [0..n] per ogni nodo di contenuto
  • da 2 in poi sono "continuazioni"
• Contesto di stile
  • Informazioni non geometriche
  • Possono essere condivise da frame adiacenti
  • Riferimenti contati, posseduti dai frame
• Vista
  • Clipping, z-index, trasparenza
  • [0..1] per ogni frame, posseduto dal frame
• Widget
  • Finestra nativa
  • [0..1] per ogni vista, posseduto dalla vista

Strutture di dati fondamentali

Contenuto

Strutture di dati fondamentali

Contenuto

Frame

Strutture di dati fondamentali

Contenuto

Frame

Contesti di stile

Strutture di dati fondamentali

Contenuto

Frame

Viste

Contesti di stile

Strutture di dati fondamentali

Contenuto

Frame

Viste

Widgets

Contesti di stile

Strutture di dati fondamentali

• Il documento possiede il modello di contenuto, e una o più presentazioni
  • Esposto in modo programmatico attraverso le API del DOM
• La presentazione possiede la gerarchia dei frame
  • I frame possiedono i contesti di stile, le viste, i widgets
  • La presentazione ha un tipo di media, dimensioni, ecc.
  • Non possono essere manipolati direttamente

Analisi dettagliata

• Impostazioni iniziali
• Costruzione del modello di contenuto
• Costruzione dei frame
• Risoluzione di stile
• Reflow
• Painting

Impostazioni iniziali

• Presupposta la conoscenza di base dell'embedding e delle API di rete (doc shell, flussi)
• Le DLL del contenuto registrano una Document Loader Factory in modo automatico
  • @mozilla.org/content-viewer-factory/
view;1?type=text/html
  • Tutti i tipi MIME correlati alla stessa classe, nsContentDLF
• nsDocShell
  • Riceve il contenuto in entrata attraverso nsDSURIContentListener
  • Invoca nsIDLF::CreateInstance, passa il tipo MIME a DLF
• nsContentDLF
  • Crea un oggetto nsHTMLDocument, invoca StartDocumentLoad.
    • Crea un parser, restituito come nsIStreamListener alla docshell
    • Crea un sink di contenuto, che viene linkato al parser e al documento
    • Crea un parser, restituito come nsIStreamListener alla docshell
    • Crea un sink di contenuto, che viene linkato al parser e al documento
• DocumentViewerImpl crea Pres Context e Pres Shell

Impostazioni iniziali

Costruzione del modello di contenuto

• Il contenuto arriva dalla rete attraverso nsIStreamListener::OnDataAvailable
• Il parser tokenizza ed elabora il contenuto; invoca i metodi su nsIContentSink con oggetti di nodo parser
  • Avviene a questo punto una memorizzazione ed una sistemazione
  • OpenContainer, CloseContainer, AddLeaf
• Il sink di contenuto crea ed allega nodi di contenuto usando l'interfaccia nsIContent
  • Il sink di contenuto mantiene uno stack degli elementi "vivi"
  • Avviene a questo punto un'ulteriore memorizzazione e sistemazione
  • InsertChildAt, AppendChildTo, RemoveChildAt

Costruzione del modello di contenuto

Costruzione dei frame

• Il sink di contenuto usa l'interfaccia nsIDocument per notificare i ∆ nel modello di contenuto
  • ContentAppended, ContentInserted, ContentRemoved
• PresShell viene registrata come osservatore del documento
  • Riceve ContentAppended, ecc., avvisi
  • Li passa all'insieme di oggetti di stile, che a sua volta li passa al costruttore di frame
• Il costruttore di frame crea i frame
  • ConstructFrameInternal passa in rassegna in modo ricorsivo l'albero del contenuto, risolve gli stili e crea i frame
  • Creati per tag (<select>) o per tipo di visualizzazione (<p>)
• Il frame manager mantiene una correlazione tra contenuto e frame

Costruzione dei frame

Risoluzione di stile

• Calcolo delle informazioni di stile in base alle regole di stile che si applicano per il nodo di contenuto del frame
• Dati di stile divisi in diverse strutture
  • Display, visibility, font, color, background,...
  • Inherit contro reset
• L'oggetto Style Context è un segnaposto per i dati di stile calcolati parzialmente
  • I dati di stile vengono calcolati lentamente, come richiesto

Reflow

• Calcolo ricorsivo della geometria (x, y, w, h) per i frame, le viste e i widgets
  • Dati w & h restrizioni del frame radice, si calcoli (x, y, w, h) per tutti i figli
  • Restrizioni propagate "in basso" attraverso nsHTMLReflowState
  • Dimensioni desiderate restituite "in alto" attraverso nsHTMLReflowMetrics
• Struttura di base
  • Il frame genitore inizializza lo stato di reflow del figlio (w, h disponibili); posiziona il frame figlio (x, y); invoca il metodo Reflow del figlio
  • Il frame figlio calcola le dimensioni desiderate, le restituisce attraverso la metrica del reflow
  • Il frame genitore dimensiona la vista e il frame figlio in base alla metrica del figlio
• N.B. molti non funzionano in questo modo! (Tabelle, blocchi, box XUL)

Reflow

• Reflow "globali"
  • Iniziale, ridimensionamento, cambiamento di stile
  • Elaborato subito attraverso il metodo PresShell
• Reflow incrementali
  • Indirizzati ad un frame specifico
  • Sporchi, modificati dal contenuto, dallo stile, definiti dall'utente
  • L'oggetto nsHTMLReflowCommand incapsula le informazioni
  • Vengono messe in coda ed elaborate in modo asincrono, nsIPressShell::AppendReflowCommand, ProcessReflowCommands

Painting

• Man mano che il reflow procede attraverso la gerarchia dei frame, le aree vengono invalidate tramite nsIViewManager::UpdateView
• A meno che non siano immediate, le aree non valide vengono unite e elaborate in modo asincrono attraverso gli eventi del sistema operativo
• Gli eventi del sistema operativo sono passati ai widget; i widget li delegano al gestore delle viste
• Il gestore delle viste rende le viste, invocando il metodo Paint di PresShell
• PresShell::Paint passa dalla vista al frame; invoca nsIFrame::Paint per ciascun livello

Incrementalismo

• A thread singolo
  • Semplice (nessun locking)
  • Non si possono trascurare le code degli eventi
• La costruzione del contenuto si dipana "a piacimento"
  • Il parser e il sink di contenuto eseguono una qualche memorizzazione
  • Il sink di contenuto ha dei "limiti di notifica"
  • Compromesso tra efficienza ed affidabilità
• La costruzione dei frame va verso il compimento
• Il parsing CSS va verso il compimento
• Il reflow va verso il compimento (per lo più)
• Il painting va verso il compimento

Incrementalismo

Futuri talk tecnici

• Modello di contenuto e DOM – jst, jkeiser
• Parser e sink di contenuto (o contenuto non valido) – harishd
• Eventi – saari, joki
• Reflow Block– e –line – waterson, dbaron
• Reflow delle tabelle – karnaze
• Controlli dei form – rods, bryner
• Risoluzione di stile ed albero delle regole – dbaron
• Viste, widget e painting – roc, kmcclusk
• Editor – kin, jfrancis
• Layout XUL e box – hewitt, ben
• XBL – hewitt, ben

Conclusione

• Flusso di dati
• Strutture di dati fondamentali
• Analisi dettagliata
• Incrementalismo
• Q & A?