Les applications envoient des commandes au serveur graphique, qui se charge de les exécuter et de faire le rendu. C'est comme ça que marche l'app_server de BeOS, et celui de Haiku (sans support de l'accélération 3D pour le moment). Bon, il y a quand même un framebuffer côté serveur. Pour BeOS, le rendu 2d est partiellement accéléré par la carte graphique (copies de blocs, opérations simples comme le tracé de lignes horizontales ou verticales, curseur de souris). Pour Haiku, ce n'est plus le cas: l'"accélération" 2D sur les cartes modernes est tombée en désuétude, et elle est souvent plus lente qu'un rendu par le CPU (et en plus, sans faire d'antialiasing et ce genre de choses). Il faudrait remettre ça en place, peut-être en utilisant OpenVG?
C'est aussi comme ça que X11 devrait fonctionner, sauf que les commandes disponibles (tracé de lignes, de pixels, etc) sont assez limitées (pas de 3D, pas d'antialiasing). Du coup, les toolkits graphiques modernes n'utilisent plus ces commandes et font tout le rendu côté client, avant d'envoyer une grosse image au serveur X.
Pour avoir un serveur X qui marche "normalement", il faut un desktop approprié, utilisant par exemple l'environnement de bureau CDE, et des applications Motif ou Athena ou ce genre de trucs.
En ce qui concerne la notion de "frame", elle est déjà en train de disparaître du côté des écrans avec le DisplayPort, qui n'a plus besoin d'un framerate fixe à 60Hz. ça règle déjà une bonne partie des problèmes (pas de "tearing", en particulier). Donc, il serait logique de faire la même chose côté logiciel.
# BeOS le faisait il y a 15 ans!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Une idée à prendre : un nouveau type de serveur d’affichage (remplaçant X ou Wayland). Évalué à 10.
Les applications envoient des commandes au serveur graphique, qui se charge de les exécuter et de faire le rendu. C'est comme ça que marche l'app_server de BeOS, et celui de Haiku (sans support de l'accélération 3D pour le moment). Bon, il y a quand même un framebuffer côté serveur. Pour BeOS, le rendu 2d est partiellement accéléré par la carte graphique (copies de blocs, opérations simples comme le tracé de lignes horizontales ou verticales, curseur de souris). Pour Haiku, ce n'est plus le cas: l'"accélération" 2D sur les cartes modernes est tombée en désuétude, et elle est souvent plus lente qu'un rendu par le CPU (et en plus, sans faire d'antialiasing et ce genre de choses). Il faudrait remettre ça en place, peut-être en utilisant OpenVG?
C'est aussi comme ça que X11 devrait fonctionner, sauf que les commandes disponibles (tracé de lignes, de pixels, etc) sont assez limitées (pas de 3D, pas d'antialiasing). Du coup, les toolkits graphiques modernes n'utilisent plus ces commandes et font tout le rendu côté client, avant d'envoyer une grosse image au serveur X.
Pour avoir un serveur X qui marche "normalement", il faut un desktop approprié, utilisant par exemple l'environnement de bureau CDE, et des applications Motif ou Athena ou ce genre de trucs.
En ce qui concerne la notion de "frame", elle est déjà en train de disparaître du côté des écrans avec le DisplayPort, qui n'a plus besoin d'un framerate fixe à 60Hz. ça règle déjà une bonne partie des problèmes (pas de "tearing", en particulier). Donc, il serait logique de faire la même chose côté logiciel.