C'est exactement le même principe mais fait à un niveau d'abstraction différent. Au lieu des boundings box c'est des éléments du dom.
Cela n'a pas la meme fonction et n'a pas non plus les memes impacts. Tout d'abord, l'objectif d'une telle optimisation base sur le n-buffering est de sauver de la bande passante. Compare au double DOM qui lui tente de sauver des performances lors de la traverse de la barriere JS/DOM (qui est necessaire, car les appels au DOM stop les optimisations de type JIT). Il n'y a pas d'amelioration de bande passante memoire ni de reduction de ce qui va etre rendu a l'ecran. Cela evite juste de faire des appels qui n'auraient du rien coute, mais qui coute dans le monde web. C'est aussi pour ca que l'implementation dans les navigateurs web d'un double DOM n'aurait pas d'impact sur les performances des applications JS.
De plus, les boundings box, c'est des objets tres sympa, ca tiens sur 4 entiers et un booleen. Tu peux les utiliser directement dans le GPU. Et enfin, tu n'as pas besoin de les reallouer entre deux frames, car elles sont tres facilement reutilisable. Tu peux optimiser ta structure memoire pour qu'elle soit bien lineaire et que les cache memoire apprecie. Pour plus de lecture: https://raphlinus.github.io/rust/graphics/gpu/2022/02/24/piet-gpu-clipping.html .
Enfin tu pourras en conclure que un navigateur web, meme si il fait du rendu d'un truc qui utilise react, aura toujours a gagner a implementer des optimisations de type n-bufferring. Et le double DOM serait probablement moins utile si il etait possible de faire des appels DOM directement depuis le code JIT au lieu de repasser en mode interprete.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Cela n'a pas la meme fonction et n'a pas non plus les memes impacts. Tout d'abord, l'objectif d'une telle optimisation base sur le n-buffering est de sauver de la bande passante. Compare au double DOM qui lui tente de sauver des performances lors de la traverse de la barriere JS/DOM (qui est necessaire, car les appels au DOM stop les optimisations de type JIT). Il n'y a pas d'amelioration de bande passante memoire ni de reduction de ce qui va etre rendu a l'ecran. Cela evite juste de faire des appels qui n'auraient du rien coute, mais qui coute dans le monde web. C'est aussi pour ca que l'implementation dans les navigateurs web d'un double DOM n'aurait pas d'impact sur les performances des applications JS.
De plus, les boundings box, c'est des objets tres sympa, ca tiens sur 4 entiers et un booleen. Tu peux les utiliser directement dans le GPU. Et enfin, tu n'as pas besoin de les reallouer entre deux frames, car elles sont tres facilement reutilisable. Tu peux optimiser ta structure memoire pour qu'elle soit bien lineaire et que les cache memoire apprecie. Pour plus de lecture: https://raphlinus.github.io/rust/graphics/gpu/2022/02/24/piet-gpu-clipping.html .
Enfin tu pourras en conclure que un navigateur web, meme si il fait du rendu d'un truc qui utilise react, aura toujours a gagner a implementer des optimisations de type n-bufferring. Et le double DOM serait probablement moins utile si il etait possible de faire des appels DOM directement depuis le code JIT au lieu de repasser en mode interprete.