Effectivement tres different de la stack Linux. Le principe ici, si j'ai bien compris, est que l'application construit une liste de ce qu'elle veut rendre a l'ecran et la donne a un thread en charge du rendu. Celui-ci est synchronise par le serveur graphique (equivalent de X) qui va en fait definir une zone de clip a l'ecran et laisser le thread de rendu faire le rendu de la fenetre en question directement dans le buffer de l'ecran.
Sous Linux, l'evolution de tous les toolkits graphiques est allez vers l'utilisation d'un systeme a multiple buffer qui est donne au compositeur. C'est a dire que l'application n'a jamais acces directement a l'ecran. Apres chaque toolkit peut si il le veut faire le rendu dans un thread de maniere asynchrone avant de donner le buffer au serveur graphique. C'est ce que font a ma connaissance les EFL et Qt/QML.
Je me demande d'ailleur comment s'en sort Haiku avec OpenGL, car ca me semble tres difficile a implementer dans un tel contexte.
[^] # Re: Intérêt
Posté par cedric . En réponse à la dépêche Haiku est vivant. Évalué à 3.
Effectivement tres different de la stack Linux. Le principe ici, si j'ai bien compris, est que l'application construit une liste de ce qu'elle veut rendre a l'ecran et la donne a un thread en charge du rendu. Celui-ci est synchronise par le serveur graphique (equivalent de X) qui va en fait definir une zone de clip a l'ecran et laisser le thread de rendu faire le rendu de la fenetre en question directement dans le buffer de l'ecran.
Sous Linux, l'evolution de tous les toolkits graphiques est allez vers l'utilisation d'un systeme a multiple buffer qui est donne au compositeur. C'est a dire que l'application n'a jamais acces directement a l'ecran. Apres chaque toolkit peut si il le veut faire le rendu dans un thread de maniere asynchrone avant de donner le buffer au serveur graphique. C'est ce que font a ma connaissance les EFL et Qt/QML.
Je me demande d'ailleur comment s'en sort Haiku avec OpenGL, car ca me semble tres difficile a implementer dans un tel contexte.