Avec le compositing, une appli ne sait jamais si elle est visible ou pas, et c'est très bien comme ça sinon ça pose d'autres problèmes.
Pas sous X. Sous X lorsqu'une application est iconifie, sa fenetre n'est plus mappe et il est donc possible pour le toolkit de le detecter. Et pour le focus, c'est pareil, on peut parfaitement le detecter et agir en consequence. Savoir comment une fenetre est utilise, est tres pratique pour pas mal de cas. Pense par exemple que tu as un pager qui affiche une miniature d'une fenetre ouverte sur un desktop virtuel que tu ne vois pas autrement, a quoi cela sert-il de rafraichir son contenu en haute resolution a 60fps ? Est-ce que ca ne vaudrait pas le cout de ne negocier qu'une mini version avec une mise a jour plus lente ? Il y a plein d'effet exigeant pour le CPU et le GPU sur un desktop qui s'y ils avaient a manipuler des fenetres plus adapte a la sortie sur l'ecran, consommerait nettement moins de ressource (et donc pourrer tourner sur des machines plus limite).
Pourquoi une liste serait dans un plan différent, ça apporte quoi? Ne pas avoir à re-rendre la liste?
Tu decoupes la liste en 3 morceaux de chacun 2/3 de la taille de la liste a l'ecran. Tu remplis chaque morceau en avance, puis tu ne fais que deplacer les elements. Quand tu depasses les 1/3 de la liste dans une direction ou dans l'autre, tu ne redessines en asynchrone qu'un des trois buffers. Ca limite grandement les chances de frame drop et tu as une tres faible utilisation CPU et GPU, donc basse consomation et fonctionne sur une plus grande gamme de materiel.
Je sais pas à quel vitesse on peut allouer un plan, mais ça devrait pas être trop lent.
En general, c'est tres lent et on est oblige (en tout cas sous X) de faire des caches pour ne pas en allouer trop souvent. Il ne faut pas obliger que entre deux images, on n'a que 16ms pour tout faire...
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 3.
Pas sous X. Sous X lorsqu'une application est iconifie, sa fenetre n'est plus mappe et il est donc possible pour le toolkit de le detecter. Et pour le focus, c'est pareil, on peut parfaitement le detecter et agir en consequence. Savoir comment une fenetre est utilise, est tres pratique pour pas mal de cas. Pense par exemple que tu as un pager qui affiche une miniature d'une fenetre ouverte sur un desktop virtuel que tu ne vois pas autrement, a quoi cela sert-il de rafraichir son contenu en haute resolution a 60fps ? Est-ce que ca ne vaudrait pas le cout de ne negocier qu'une mini version avec une mise a jour plus lente ? Il y a plein d'effet exigeant pour le CPU et le GPU sur un desktop qui s'y ils avaient a manipuler des fenetres plus adapte a la sortie sur l'ecran, consommerait nettement moins de ressource (et donc pourrer tourner sur des machines plus limite).
Tu decoupes la liste en 3 morceaux de chacun 2/3 de la taille de la liste a l'ecran. Tu remplis chaque morceau en avance, puis tu ne fais que deplacer les elements. Quand tu depasses les 1/3 de la liste dans une direction ou dans l'autre, tu ne redessines en asynchrone qu'un des trois buffers. Ca limite grandement les chances de frame drop et tu as une tres faible utilisation CPU et GPU, donc basse consomation et fonctionne sur une plus grande gamme de materiel.
En general, c'est tres lent et on est oblige (en tout cas sous X) de faire des caches pour ne pas en allouer trop souvent. Il ne faut pas obliger que entre deux images, on n'a que 16ms pour tout faire...