Oui, c'est la téchnique du shadow DOM. Mais tu veux dire que tu peux recréer complètement tout tes widgets à la volé à chaque modification du modèle applicatif sans perte de performance ? J'ai un gros doute.
Non, j'expliquais comment fonctionne react et pourquoi il fonctionne comme ca. Tu n'as pas besoin d'avoir un shadow DOM ou equivalent quand tu fais du natif, car tu n'as pas ces barrieres couteuses.
Dans le cadre d'un toolkit natif, tu as deux morceaux, l'API de widget et la logique de rendu de ces widgets a l'ecran. Dans une API de type "immediat", tu vas avoir un evenement de type "paint" a chaque frame qui va te demander de redessiner le contenu de ton widget. La complexite du rendu est donc deporte dans le widget, voir l'application (cela depend de l'API du widget). Dans une API de type "retained", le code du widget modifie des primitives sur le canvas et c'est le canvas qui va alors voir si il y a un changement lors de la prochaine frame. Ca donne plus de possibilite d'optimisation, car le canvas a une vue globale de ce qu'il y a a faire.
Globalement, dans ces deux cas, tu peux faire des optimisations de type shadow DOM, ce qui limitera les appels sur les API des widgets. Dans le cas d'une API de type immediat, cela payera probablement. Par contre dans le cas, d'une API "retained", c'est tres peu probable voir l'inverse, car cela va augmenter la consommation de memoire et donc la consommation de bande passante qui est la principale ressource limitante pour une application native.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 3.
Non, j'expliquais comment fonctionne react et pourquoi il fonctionne comme ca. Tu n'as pas besoin d'avoir un shadow DOM ou equivalent quand tu fais du natif, car tu n'as pas ces barrieres couteuses.
Dans le cadre d'un toolkit natif, tu as deux morceaux, l'API de widget et la logique de rendu de ces widgets a l'ecran. Dans une API de type "immediat", tu vas avoir un evenement de type "paint" a chaque frame qui va te demander de redessiner le contenu de ton widget. La complexite du rendu est donc deporte dans le widget, voir l'application (cela depend de l'API du widget). Dans une API de type "retained", le code du widget modifie des primitives sur le canvas et c'est le canvas qui va alors voir si il y a un changement lors de la prochaine frame. Ca donne plus de possibilite d'optimisation, car le canvas a une vue globale de ce qu'il y a a faire.
Globalement, dans ces deux cas, tu peux faire des optimisations de type shadow DOM, ce qui limitera les appels sur les API des widgets. Dans le cas d'une API de type immediat, cela payera probablement. Par contre dans le cas, d'une API "retained", c'est tres peu probable voir l'inverse, car cela va augmenter la consommation de memoire et donc la consommation de bande passante qui est la principale ressource limitante pour une application native.