Over Cairo in Firefox 3
Ze gaan in Firefox 3 voor alle rendering gebruik maken van de Cairo libraries.
http://cairographics.org/
Cairo is bewust 2D only graphics library. Het kan direct outputten via DirectX, OpenGL, etc. Maar ook zijn resultaat als een Postscript of PDF renderen.
Het de laatste tijd de defacto standaard geworden op Linux voor 2D rendering. De meeste GTK-engines maken er inmiddels gebruik van bijvoorbeeld. Behalve dat het dus een soort crossplatform-direct-rendering oplevert, is het ook heel programmeurs-vriendelijk.
Je kunt allerlei soorten 2D effecten toepassen van Bezier-curves en anti-aliasing tot en met de triviale zaken als rotate en schalen. De aanpak is slim omdat elke sequentie van handelingen tot een matrix vermenigvuldiging kan worden terug-gebracht. Net als bij 3D, maar dan een 3x3 matrix ipv een 4x4 matrix.
http://en.wikipedia.org/wiki/Affine_transformation
Hierdoor wordt een zoom+rotatatie+transformatie niet langzamer dan alleen een zoom bijvoorbeeld. Bijkomend voordeel is dat zulke berekeningen aan de meeste moderne 3D kaarten kunnen worden overgelaten ;-)
Dus JA, Het renderen zal minstens net zo snel worden als Opera. Alhoewel je niet moet denken dat het renderen als enige hetgene is wat opera zo snel maakt. Het lastige aan HTML renderen is dat HTML geen specieke weergave bevat, maar formeel gezien alleen een zooi constraints.
http://en.wikipedia.org/wiki/Constraint_programming
Het Probleem van HTML Renderen
Het grote probleem is text en plaatjes zonder vooraf opgeven dimensies. De enige manier om er achter te komen wat de minimale breedte van "Hallo, Tweakers!" zou zijn is de font-api's aan te roepen en het daadwerkelijk te renderen. Dat kost geheugen en tijd. In het ergste geval kun je de uiteindelijke versie van een pagina pas renderen als je van alle onderdelen weet wat de minimale breedte en hoogte is.
Een voorbeeld: een simpele tabel:
Neem nou dit stukje html:
<table border='1'>
<tr><td align='center'>Hallo, Tweakers!</td></tr>
<tr><td align='center'>erg kort</td></tr>
<tr><td align='center'>Deze cell is het breedste van allemaal !!</td></tr>
</table>
Om de cellen van deze tabel te kunnen renderen met de text gecentreerd moeten we eerst weten hoe breed de tabel wordt.
Om te weten hoe breed de tabel wordt moeten we weten hoe breed de breedste cell van de tabel wordt.
Dit is wat de meeste render-engines doen:
- render alle tabel-cellen om te ontdekken welke het breedst is
- render daarna alle cellen opnieuw in die breedte met de juiste hoeveelheid ruimte eromheen zodat de text in het midden uitkomt.
Of te wel, elke cell wordt nu twee keer gerendert. Als het een hele lange tabel is zal hij ook erg langzaam laden. Probeer maar eens met een tabel met 5000 rij-en. Niet alleen moet alle HTML-code al gedownload zijn wil de weergave 'correct' zijn, alles moet ook al minstens 1 keer gerendert zijn. Zelfs als we alle niet zichtbare cellen weer uit het geheugen weggooien zullen we op zijn minst aardig wat CPU kwijt zijn aan het renderen van al die cellen.
Besef daarna dat je met Javascript ook nog eens de inhoud van een cell kan aanpassen en je kunt je voorstellen dat het schrijven van een efficient layout-systeem dat ook real-time wijzigingen kan doorvoeren lastig is.
Misschien dat velen van jullie nu zitten te denken van 'dat kan sneller' .. en jullie hebben gelijk. Maar elke optimizalisatie maakt het proccess veel ingewikkelder en het uiteindelijke render gedrag onvoorspelbaarder.
Daarnaast zijn de render-engines zijn niet van de grond af aan opgebouwd met DHTML en javascript in het achterhoofd. Ze zijn ge-evoluteerd vanuit versies die totaal andere vereisten hadden. Het is extra lastig omdat diezelfde render-engine ook backwards compatible moet zijn aan de quirk-modes en de bugs in oudere versies van de render-engines.
http://en.wikipedia.org/wiki/Quirks_mode
Alhoewel ik Microsoft en Mozilla van harte oproep om gezamelijk te besluiten de quirk-mode gewoon eruit te slopen en het renderen van incorrecte xhtml keihard te weigeren. Het zal even pijn doen aan de industrie, maar op termijn zal het alleen maar voordelen hebben.
De html-standaarden bestaan helemaal niet
Niet dat het wonderen zou doen. De standaarden zijn totaal onvolledig. Ze
defineren wat een geldig xhtml-document zou moeten zijn. Daarmee kan je een document ondubbelzinnig als 'geldig' of 'ongeldig' classificeren. Ze
suggereren slechts hoe het dan gerendert wordt. Hoe bold is bold? Hoe breed is een ridge-border precies? Wat doe je als een lettertype vereist is dat niet beschikbaar is? Welke kleur is de text-selectie kleur? Wat doe je als je niet aan constraints _kan_ voldoen. Stel dat je maximum-height en maximum-widt defineert en dat de afgebroken text nog steeds niet past? Wordt de inhoud dan breder (met mogelijkerwijs een horizontale scrollbar) of wordt het hoger (met mogelijkerwijs een verticale scrollbar). Zo kan je nog wel even doorgaan...
Een geldig xhtml-document en twee standard-compliance-browsers betekent nog niet dat ze ook identiek zullen functioneren. Het gedrag van de renderer is namelijk niet in totaliteit te formaliseren: je kan je geen waterproof tool schrijven die beoordeelt of twee render-engines bij elke mogelijk xhtml-document identiek hetzelfde gedrag zullen gaan vertonen.
De web-standaarden zijn dus net zo formeel als het wetboek van strafrecht. Er zal altijd ruimte voor interpratie verschillen zijn...