[...] il faudrait que le programme client puisse faire le rendu en utilisant l'acceleration materielle (et idealement directement dans la mémoire de la carte graphique si l'affichage est local)
Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !
Maintenant, lorsqu'une application (ou un toolkit graphique) veut utiliser l'accélération matérielle, elle utilise l'api OpenGL en court-circuitant le serveur X. Donc il est impossible d'utiliser openGL en affichage déporté (sauf bidouille, mais cela n'aurait aucun intéret de tt façon).
et ensuite passe une reference vers l'image au serveur X qui idéalement utiliserait aussi l'acceleration materielle pour composer ces image dans le rendu final
C'est à peu de choses près ce qu'il se passe actuellement. Lorsque le serveur X est en mode RenderAccel (EXA, XAA,...), il utilse des optimisations implémentées par le pilotes de la CG. On peut aussi utiliser un composeur (?) style compiz qui utilise le contexte OpenGL de la cg.
1) tous les clients et le serveur partageant la carte graphique: ça ne pose pas un probleme? Au départ, les cartes graphique avaient 'un seul maitre' pour l'acceleration 3D il me semble.
C'est toujours le cas et ce n'est pas près de changer. C'est la même chose que faire du multi-tâche alors qu'on a qu'un seul CPU: il faut le partager entre les applications en sauvegardant/restaurant leur contexte respectif.
j'ai l'impression que si le serveur X compose des 'images' fourni par le client, au niveau rendu des fontes ça risque d'être l'horreur: pas de possibilité de faire de l'anti-aliasing propre tant que tu ne connais pas ton positionement par rapport aux pixels (tant que le DPI des écrans reste assez faible :-( ).
Étant donné que l'on n'a pas encore inventé les pixels quantiques, l'image envoyée par le client sera toujours alignée sur un pixel (logique, non ?). L'AA est fait par le client, s'il veut que sont image puisse être composée, il n'a qu'à y avoir des pixels (semi-)transparents...
Je ne comprends pas bien pourquoi on parle d'image fourni par le client: si le client fournissait des vecteur et du texte a la place d'image
Le protocol X permet cela mais ces instructions restent basiques.
(ce que fait Cairo il me semble non?),
Non, justement c'est à cairo que l'on demande de dessiner des formes vectorielles dans un pixmap, que l'on envoit ensuite au serveur X. Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire. Ce serait aussi la voie vers une explosion de la complexité du protocol X (il faudra une nouvelle version du protocole à chaque fois que tu voudrais utiliser un nouveau type de flou ?!).
le rendu et la composition étant fait par le serveur, ces problemes la disparaitraient non?
À quels problèmes fait tu références ?
L'avantage de cette architecture c'est que le rendu et la composition sont effectués par ceux qui sont le mieux disposés à le faire. Et avec un compositeur style compiz, on arrive même à masquer la latence engendrée lorque le serveur X demande à une fenêtre de se redessiner.
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par benja . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 2.
Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !
Maintenant, lorsqu'une application (ou un toolkit graphique) veut utiliser l'accélération matérielle, elle utilise l'api OpenGL en court-circuitant le serveur X. Donc il est impossible d'utiliser openGL en affichage déporté (sauf bidouille, mais cela n'aurait aucun intéret de tt façon).
et ensuite passe une reference vers l'image au serveur X qui idéalement utiliserait aussi l'acceleration materielle pour composer ces image dans le rendu final
C'est à peu de choses près ce qu'il se passe actuellement. Lorsque le serveur X est en mode RenderAccel (EXA, XAA,...), il utilse des optimisations implémentées par le pilotes de la CG. On peut aussi utiliser un composeur (?) style compiz qui utilise le contexte OpenGL de la cg.
1) tous les clients et le serveur partageant la carte graphique: ça ne pose pas un probleme? Au départ, les cartes graphique avaient 'un seul maitre' pour l'acceleration 3D il me semble.
C'est toujours le cas et ce n'est pas près de changer. C'est la même chose que faire du multi-tâche alors qu'on a qu'un seul CPU: il faut le partager entre les applications en sauvegardant/restaurant leur contexte respectif.
j'ai l'impression que si le serveur X compose des 'images' fourni par le client, au niveau rendu des fontes ça risque d'être l'horreur: pas de possibilité de faire de l'anti-aliasing propre tant que tu ne connais pas ton positionement par rapport aux pixels (tant que le DPI des écrans reste assez faible :-( ).
Étant donné que l'on n'a pas encore inventé les pixels quantiques, l'image envoyée par le client sera toujours alignée sur un pixel (logique, non ?). L'AA est fait par le client, s'il veut que sont image puisse être composée, il n'a qu'à y avoir des pixels (semi-)transparents...
Je ne comprends pas bien pourquoi on parle d'image fourni par le client: si le client fournissait des vecteur et du texte a la place d'image
Le protocol X permet cela mais ces instructions restent basiques.
(ce que fait Cairo il me semble non?),
Non, justement c'est à cairo que l'on demande de dessiner des formes vectorielles dans un pixmap, que l'on envoit ensuite au serveur X. Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire. Ce serait aussi la voie vers une explosion de la complexité du protocol X (il faudra une nouvelle version du protocole à chaque fois que tu voudrais utiliser un nouveau type de flou ?!).
le rendu et la composition étant fait par le serveur, ces problemes la disparaitraient non?
À quels problèmes fait tu références ?
L'avantage de cette architecture c'est que le rendu et la composition sont effectués par ceux qui sont le mieux disposés à le faire. Et avec un compositeur style compiz, on arrive même à masquer la latence engendrée lorque le serveur X demande à une fenêtre de se redessiner.