Je crois que tu n'as pas encore compris toi meme les tenants et les aboutissants. Ils sont nombreux et peux claire alors c'est comprehensible. Je vais tanter de les resumer ici.
Tout d'abord oui la transparence est une operation couteux avec le protocol X pour la simple est bonne raison que jusqu'a present l'acceleration de l'extension render laisse pour le moins a desirer. Note q'ici il s'agit pas d'une simple transparence opaque ou totalement transparent. La complexite des operations en jeux est bien presente dans ce document: http://keithp.com/~keithp/talks/KeithPackardAls2000/index.ht(...)
L'acceleration exa perment en partie de combler le retard mais beaucoup pensent que l'avenir s'oriente plutot vers une solution du type glucose (une adaptation de xgl pour simplifier dans les grandes lignes).
Ensuite les drivers libre intel dans leur branches fbo supporte le rendu opengl off screen et je te met au defis de prouver le contraire (si j'etais riche je parierai tout mon argent ou je ferrai comme notre amis Patrick qui fait un all in alors que le mec en face bluff pas...on t'en veux pas Patrick)
Le probleme auquel tu fais reference viens de l'architecture de l'acceleration opengl sous X window pour les driver libre: DRI. DRI c'est direct rendering infrastructure ou en francais dans le texte infrastructure pour le rendu direct. Comme dans tout bon film de serie E tu t'apercois que le mechant c'est pas celui que tu pense mais en faites un mec qui se faisait passer pour un gentil.
Donc le DRI ca permet aux applications opengl de faire leur rendu directement dans le framebuffer le truc qui est afficher a l'ecran; ca evite de faire une copie entre un buffer temporaire et l'ecran. Et tout ca se passe dans le dos du serveur X. Tant qu'on etait avec un serveur X tout bete en 2d aucun probleme mais quand on a un composite manager alors la plus rien ne va car le composite manager est incapable de recuperer l'image de l'application opengl proprement.
Voila pour la petite histoire. Maintenant la solution (il y a toujours une happy end c'est la regle on n'y peut rien...) passe par une modification de cette infrastructure c'est ce qui est connu aujourd'hui sous le nom de dri2 (le titre finale n'est pas connu mais ca sera un truc du genre: la revanche, il revient et ca va en jeter un max...on fait avec le budget qu'on a desole...). Et au passage dri2 necessitera d'avoir un gestionnaire de memoire digne de se nom qu'on appel aujourd'hui par abus de langague ttm.
Voila, il y aurait problablement de quoi ecrire un bouquin tant les choses sont encore plus complexe (au moins dans leur realisation) que je ne les ai ici presenter. Mais ca ferai un mauvais polar...
[^] # Re: Zarb
Posté par Markov . En réponse au journal GTK+ et OpenGL pour bientot ??. Évalué à 1.
Tout d'abord oui la transparence est une operation couteux avec le protocol X pour la simple est bonne raison que jusqu'a present l'acceleration de l'extension render laisse pour le moins a desirer. Note q'ici il s'agit pas d'une simple transparence opaque ou totalement transparent. La complexite des operations en jeux est bien presente dans ce document:
http://keithp.com/~keithp/talks/KeithPackardAls2000/index.ht(...)
L'acceleration exa perment en partie de combler le retard mais beaucoup pensent que l'avenir s'oriente plutot vers une solution du type glucose (une adaptation de xgl pour simplifier dans les grandes lignes).
Ensuite les drivers libre intel dans leur branches fbo supporte le rendu opengl off screen et je te met au defis de prouver le contraire (si j'etais riche je parierai tout mon argent ou je ferrai comme notre amis Patrick qui fait un all in alors que le mec en face bluff pas...on t'en veux pas Patrick)
Le probleme auquel tu fais reference viens de l'architecture de l'acceleration opengl sous X window pour les driver libre: DRI. DRI c'est direct rendering infrastructure ou en francais dans le texte infrastructure pour le rendu direct. Comme dans tout bon film de serie E tu t'apercois que le mechant c'est pas celui que tu pense mais en faites un mec qui se faisait passer pour un gentil.
Donc le DRI ca permet aux applications opengl de faire leur rendu directement dans le framebuffer le truc qui est afficher a l'ecran; ca evite de faire une copie entre un buffer temporaire et l'ecran. Et tout ca se passe dans le dos du serveur X. Tant qu'on etait avec un serveur X tout bete en 2d aucun probleme mais quand on a un composite manager alors la plus rien ne va car le composite manager est incapable de recuperer l'image de l'application opengl proprement.
Voila pour la petite histoire. Maintenant la solution (il y a toujours une happy end c'est la regle on n'y peut rien...) passe par une modification de cette infrastructure c'est ce qui est connu aujourd'hui sous le nom de dri2 (le titre finale n'est pas connu mais ca sera un truc du genre: la revanche, il revient et ca va en jeter un max...on fait avec le budget qu'on a desole...). Et au passage dri2 necessitera d'avoir un gestionnaire de memoire digne de se nom qu'on appel aujourd'hui par abus de langague ttm.
Voila, il y aurait problablement de quoi ecrire un bouquin tant les choses sont encore plus complexe (au moins dans leur realisation) que je ne les ai ici presenter. Mais ca ferai un mauvais polar...