>>Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !<<
Aucun moyen dans l'implementation actuelle, pas dans l'absolu:
-le client pourrait utiliser sa carte graphique pour accelerer un rendu sans l'afficher, recopier l'image en mémoire principale (raisonnable depuis PCI Express pour des rendus complexes) puis l'envoyer au serveur
-si le client envoyait des vecteurs ou des commandes OpenGL au serveur, le rendu serait fait par le serveur: j'ai bien compris que ce n'est pas le cas a l'heure actuelle, mais 'aucun moyen' n'est pas correcte.
>>mais cela n'aurait aucun intéret de tt façon<<
Bin la bande passante utilisée pour envoyer des vecteur ou des commandes OpenGL est tres inferieure a celle utilisée pour envoyer des images donc dans certaines conditions (assez limitée d'accord), cela pourrait être interressant.
>>É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 ?).<<
Certes mais si la composition decale l'image d'une quantité non-entiere, le mapping des pixels n'est plus valable 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.<<
Oui j'avais oublié ça, mais ça veut dire que cairo ne peut pas utiliser l'acceleration materielle alors???
>>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.<<
Bof, le serveur pourrait cacher le rendu je ne vois pas ou est le probleme.
>>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 ?!).<<
[^] # Re: Merci pour cette dépêche, je rebondis...
Posté par reno . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 3.
Aucun moyen dans l'implementation actuelle, pas dans l'absolu:
-le client pourrait utiliser sa carte graphique pour accelerer un rendu sans l'afficher, recopier l'image en mémoire principale (raisonnable depuis PCI Express pour des rendus complexes) puis l'envoyer au serveur
-si le client envoyait des vecteurs ou des commandes OpenGL au serveur, le rendu serait fait par le serveur: j'ai bien compris que ce n'est pas le cas a l'heure actuelle, mais 'aucun moyen' n'est pas correcte.
>>mais cela n'aurait aucun intéret de tt façon<<
Bin la bande passante utilisée pour envoyer des vecteur ou des commandes OpenGL est tres inferieure a celle utilisée pour envoyer des images donc dans certaines conditions (assez limitée d'accord), cela pourrait être interressant.
>>É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 ?).<<
Certes mais si la composition decale l'image d'une quantité non-entiere, le mapping des pixels n'est plus valable 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.<<
Oui j'avais oublié ça, mais ça veut dire que cairo ne peut pas utiliser l'acceleration materielle alors???
>>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.<<
Bof, le serveur pourrait cacher le rendu je ne vois pas ou est le probleme.
>>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 ?!).<<
C'est effectivement le gros probleme..