Dans les toolkit graphique, tout redessiner est très couteux, on gère donc des modifications qui deviennent un enfer à tenir cohérent.
C'est vrai uniquement dans le cadre de la famille des toolkit graphiques "immediate". Les toolkit graphiques "retained" se souviennent en permanence de ceux qu'ils ont construit pour les frames precedentes. Ils sont alors capable de faire un delta entre le buffer que le systeme leur donne et ce que l'application veut afficher a l'ecran. Cela va plus loin que ceux que les framework web peuvent faire, car on a du recyclage de buffer video (prive a l'application). C'est a dire que lorsque un buffer a ete affiche a l'ecran on peut le reutiliser. Pas la peine d'en effacer le contenu. On peut, donc calculer les zones de l'ecran qui ont change et ne redessiner que ce qui est necessaire. Bien entendu, les framework "retained" vont pouvoir aussi memoriser le contenu des differents trucs couteux a rendre a l'ecran et les stocker dans un cache associer aux objets a afficher. Comme ceux-ci reste en vie aussi longtemps qu'on en a besoin, la gestion des caches est simplifies et optimales. Enfin comme les framework "retained" ont une vision globale de la scene qu'ils ont a rendre, ils peuvent optimiser le "clipping" des objets a peindre/calculer pour limiter la consommation de CPU et bande passante.
Il est bien entendu possible pour une application qui fait du rendu immediat d'implementer tout cela, mais c'est beaucoup de boulot comme tu le fais remarquer qui a mon sens a plus sa place dans le toolkit que dans l'application.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 5.
C'est vrai uniquement dans le cadre de la famille des toolkit graphiques "immediate". Les toolkit graphiques "retained" se souviennent en permanence de ceux qu'ils ont construit pour les frames precedentes. Ils sont alors capable de faire un delta entre le buffer que le systeme leur donne et ce que l'application veut afficher a l'ecran. Cela va plus loin que ceux que les framework web peuvent faire, car on a du recyclage de buffer video (prive a l'application). C'est a dire que lorsque un buffer a ete affiche a l'ecran on peut le reutiliser. Pas la peine d'en effacer le contenu. On peut, donc calculer les zones de l'ecran qui ont change et ne redessiner que ce qui est necessaire. Bien entendu, les framework "retained" vont pouvoir aussi memoriser le contenu des differents trucs couteux a rendre a l'ecran et les stocker dans un cache associer aux objets a afficher. Comme ceux-ci reste en vie aussi longtemps qu'on en a besoin, la gestion des caches est simplifies et optimales. Enfin comme les framework "retained" ont une vision globale de la scene qu'ils ont a rendre, ils peuvent optimiser le "clipping" des objets a peindre/calculer pour limiter la consommation de CPU et bande passante.
Il est bien entendu possible pour une application qui fait du rendu immediat d'implementer tout cela, mais c'est beaucoup de boulot comme tu le fais remarquer qui a mon sens a plus sa place dans le toolkit que dans l'application.