Je travaille sur la partie graphique de Gecko et je trouve tout à fait crédible que le rendu par DOM d'un jeu soit plus rapide que le rendu par Canvas 2D.
Le canvas 2D est dérivé de CoreGraphics lui-même dérivé de PostScript. Ce type d'API n'a pas été conçu pour des graphismes en temps réel et encore moins sur GPU, et y est inefficace pour plusieurs raisons:
- API impérative consistant en une série d'opérations, mais qui ne ressemblent pas au type d'opérations qu'un GPU effectue, et donc difficile à traduire.
- Non-séparation du rendu et de la déclaration des ressources (par exemple drawImage() déclare que le canvas va accéder à une image et demande immédiatement son rendu).
- Existence de primitives intrinsèquement difficiles à optimiser sur GPU (courbes, texte...)
- Attente d'une très haute qualité d'anti-crénelage.
Alors qu'avec le rendu d'éléments DOM, tout est déclaré à l'avance, et la scène est décrite de façon déclarative, ce qui permet au navigateur de s'organiser pour optimiser son utilisation du GPU. Bien sûr, c'est encore assez tordu et il reste bien des façons de se planter, mais ça peut facilement être mieux que canvas 2D.
Dans Firefox sur X11, pour que le rendu DOM aille vite, aller dans about:config et essayer: layers.acceleration.force-enabled=true, gfx.xrender.enabled=false. On travaille à ce que ce soit activé par défaut d'ici à quelques mois. C'est déjà par défaut sur les autres plateformes.
Note: à la question de savoir quelle API Web serait vraiment efficace pour le rendu de jeux, la réponse est bien sûr WebGL :-) dans Firefox sur X11, à nouveau, essayer avec layers.acceleration.force-enabled=true.
# DOM plus rapide que Canvas: tout à fait crédible
Posté par Benoit Jacob . En réponse à la dépêche Petit jeu en HTML5 et découverte de Crafty. Évalué à 10. Dernière modification le 22 avril 2014 à 13:29.
Je travaille sur la partie graphique de Gecko et je trouve tout à fait crédible que le rendu par DOM d'un jeu soit plus rapide que le rendu par Canvas 2D.
Le canvas 2D est dérivé de CoreGraphics lui-même dérivé de PostScript. Ce type d'API n'a pas été conçu pour des graphismes en temps réel et encore moins sur GPU, et y est inefficace pour plusieurs raisons:
- API impérative consistant en une série d'opérations, mais qui ne ressemblent pas au type d'opérations qu'un GPU effectue, et donc difficile à traduire.
- Non-séparation du rendu et de la déclaration des ressources (par exemple drawImage() déclare que le canvas va accéder à une image et demande immédiatement son rendu).
- Existence de primitives intrinsèquement difficiles à optimiser sur GPU (courbes, texte...)
- Attente d'une très haute qualité d'anti-crénelage.
Alors qu'avec le rendu d'éléments DOM, tout est déclaré à l'avance, et la scène est décrite de façon déclarative, ce qui permet au navigateur de s'organiser pour optimiser son utilisation du GPU. Bien sûr, c'est encore assez tordu et il reste bien des façons de se planter, mais ça peut facilement être mieux que canvas 2D.
Dans Firefox sur X11, pour que le rendu DOM aille vite, aller dans about:config et essayer: layers.acceleration.force-enabled=true, gfx.xrender.enabled=false. On travaille à ce que ce soit activé par défaut d'ici à quelques mois. C'est déjà par défaut sur les autres plateformes.
Note: à la question de savoir quelle API Web serait vraiment efficace pour le rendu de jeux, la réponse est bien sûr WebGL :-) dans Firefox sur X11, à nouveau, essayer avec layers.acceleration.force-enabled=true.