Integrer OpenGL directement dans GTK+ pour avoir directement de la transparence dans les fenetres, les boutons ect... sans que le developpeur de l'application code quoique se soit ??
C'est fait :)
http://arstechnica.com/news.ars/post/20071028-making-linux-a(...)
http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756(...)
http://www.cimitan.com/blog/2007/12/12/gtk-rgba-transparent-(...)
http://macslow.thepimp.net/?p=150
Il serait possible de le faire assez facile avec Qt egalement
Journal GTK+ et OpenGL pour bientot ??
21
déc.
2007
# Zarb
Posté par Pinaraf . Évalué à 2.
Parce que les fenêtres transparentes, c'est le composite manager et un canal alpha sur la fenêtre, c'est tout.
Et actuellement, seuls les pilotes nvidia supportent la redirection d'un rendu OpenGL. En clair : votre fenêtre dessinée en OpenGL n'est gérable par un composite manager qu'avec les pilotes nvidia.
L'OpenGL dans un toolkit, qu'il s'agisse de Gtk ou Qt, c'est uniquement dans l'application, sans aucune interaction avec le reste. Tu peux sans problème faire une fenêtre semi transparente sans utiliser l'OpenGL.
Là ce qui est nouveau c'est la possibilité d'avoir un widget Gtk dans une texture OpenGL, et donc de pouvoir le déformer à souhait dans l'application (rotations, déformations, homothéties... y'a l'choix)
[^] # Re: Zarb
Posté par IsNotGood . Évalué à 1.
C'est pour faire de la transparence par pixel ou par widget. Compiz c'est par fenêtre.
> Parce que les fenêtres transparentes, c'est le composite manager et un canal alpha sur la fenêtre, c'est tout.
Tu peux aussi "dessiner" le contenu des fenêtres" en ARGB (alpha par pixel). Ainsi la transparence n'est plus pour l'ensemble de la fenêtre, mais par pixel. Les quelques copies d'écran le montre clairement.
> Et actuellement, seuls les pilotes nvidia supportent la redirection d'un rendu OpenGL.
J'en doute. Ou alors tu parles de Linux uniquement.
Enfin, tu peux faire un rendu dans un texture, puis utiliser cette texture lors du render de l'écran. Ça tout le monde peut le faire je crois.
La redirection de rendu, c'est pour les trucs "tordus" type reflets, etc...
> En clair : votre fenêtre dessinée en OpenGL n'est gérable par un composite manager qu'avec les pilotes nvidia.
Non.
La fenêtre n'est qu'une texture. Ici la particularité est que la texture est remplis avec un "rendu" (la texture est une render target). Puis la texture (parmis d'autres) est utilisé pour faire l'affichage à l'écran. Il n'y a pas de rendu dans la texture pendant le rendu à l'écran. Donc quasiment tous les drivers doivent le supporter.
[^] # Re: Zarb
Posté par IsNotGood . Évalué à 2.
reflets de l'ensemble de la scène et pas seulement de ce qu'il y a dans la fenêtre.
[^] # Re: Zarb
Posté par Markov . Évalué à 1.
Enfin la chose est utile car il me semble (je peux me tromper je hais me pencher sur le protocol X) que si tu veux de la vrai transparence avec le protocol X tu tue les performances car cela necessite une relecture des pixels et tout doit repaser par le client (meme si en local ce n'est pas la partie la plus lente). Alors qu'en opengl tu dis alpha blending et la miracle ! ;)
Enfin avoir le toolkit comme gtk gerer cela permet a l'application de gerer sa transparence et non pas d'avoir la transparence sur toute la fenetre mais par exemple que des parties de celle-ci. Et il y a certainement d'autre applications a ce truc...
[^] # Re: Zarb
Posté par Pinaraf . Évalué à 3.
Redirection du rendu OpenGL : seul nVidia le supporte et ce quel que soit l'OS libre. Pour faire un essai, c'est hyper facile : lancez glxgears sur votre PC avec un compiz activé avec l'effet wobbly (les fenêtres molles), puis déplacez votre glxgears. La fenêtre ne sera pas déformée, et y'aura probablement des clignotements moches à l'écran. Si elle est déformée, sauf sur le pilote nVidia, vous êtes en rendu logiciel avec des mauvaises perfs. Ça s'améliore avec l'approche de TTM, mais c'est pas encore prêt (l'API est presque prête il me semble)
Pour faire de la transparence par pixel ou par widget : vous avez fumé quoi pour affirmer qu'il faut de l'OpenGL ? De plus, si vous voulez faire disons 1 pixel de votre fenêtre transparent (on voit à travers), vous avez besoin de l'ARGB et d'un composite manager derrière. L'OpenGL n'a strictement rien à voir là dedans.
Si la fenêtre n'est qu'une texture, dans ce cas elle n'est pas gérable dans X. X gère une fenêtre, pas une texture OpenGL. Pour afficher la texture à l'écran, faut la balancer dans quelque chose. Ce quelque chose, ben c'est une fenêtre.
Enfin, la vraie transparence avec le protocole X ne tue pas les performances. Il est heureusement inutile d'aller relire chaque fenêtre derrière vue qu'elles sont déjà dans la mémoire du composite manager. C'est l'un des intérêts de l'utilisation d'un composite manager plutôt qu'un machin dans le serveur X direct, comme suggéré par certains illuminés qui passent sur la mailing list de xorg une fois l'an proposer leurs solutions révolutionnaires sans en comprendre les tenants et les aboutissants...
[^] # Re: Zarb
Posté par IsNotGood . Évalué à 1.
Désolé d'être désagréable, mais tu fumes quoi ?
Parce je connais X dans les grandes lignes et avec X tu peux avoir des fenêtres qui sont des textures. Côté client ce n'est pas forcément une texture, mais côté serveur ça ne pose pas de problème. C'est principalement X11 qui "cause" à la carte graphique.
Ce n'est pas Compiz qui fait la transparence, c'est le serveur X11. Compiz "configure" le serveur X11 (lui dit quel est la transparence de telle ou telle fenêtre, etc).
Effectivement on n'est pas obligé d'utiliser OpenGL pour faire de la transparence. On n'est pas obligé non plus d'utiliser OpenGL pour faire de la 3D. Mais sans OpenGL les performances sont lamentables.
Juste un petit exemple. 4 fenêtres en transparence de 1600x1200 en (A)RGB32 : presque 30 Mo !
La transparence est appliquée en cascade.
Lecture des deux premières fenêtre => 15 Mo.
Résultat temporaire => 7 Mo.
Lecture du résultat temporaire et lecture de la troisième fenêtre => 15 Mo
....
Lecture = 15 *3 = 45 Mo
Ecriture = 7 * 3 = 21 Mo
Soit pour une image = 66 Mo !
Si une fenêtre est une vidéo à 25 fps et qu'elle est au fond on a au minimum => 66*25 = 1,6 Go/s !
Certes les derniers CPU peuvent peut-être supporter ça. Mais c'est très très limite.
Les cartes graphique savent bouffer ça à une vitesse "terrifiante".
Sans parler de 3D, l'autre chose que font les cartes graphiques à une vitesse "terrifiante", c'est le redimensionnement d'image et l'antialiasing (qui peut être très très coûteux si fait avec le cpu de la carte mère).
Donc OK, OpenGL n'est pas nécessaire pour la transparence. Mais il faut être con pour s'en passer.
NB : Je connais bien Direct3D (je développe avec) et je ne suis pas naïf dans ce domaine.
[^] # Re: Zarb
Posté par Pinaraf . Évalué à 2.
Bon vas-y, laisse béton. Avec un principe de base comme ça, t'es foutu, vu que c'est tout simplement faux.
Compiz dit au serveur X : ne dessine plus les fenêtres toi même, c'est moi qui me charge de te donner mes instructions à ce sujet.
Le serveur X ne sait pas, dans un composite manager, où sont dessinées les fenêtres. Il ne sait même pas si elles vont être dessinées.
[^] # Re: Zarb
Posté par Ph Husson (site web personnel) . Évalué à 2.
Ho lui il prend des opiacés de temps à autre, mais là il est normal.
La drogue c'est mal ©. Compiz communique un peu niveau affichage avec le serveur X pour obtenir un contexte OpenGL, après à supposer qu'on soit en DRI ou équivalent, compiz n'envoie plus rien au serveur X si ce n'est peut être les entrées utilisateurs.
Très belle démonstration... Dommage que y a un "petit" détail, tu considère que la seule manière d'utiliser un GPU sous Linux c'est OpenGL. Pas de pot c'est strictement faux.
Et moi je connais les bus assez bien (je les utilise tous les jours).
[^] # Re: Zarb
Posté par Pinaraf . Évalué à 2.
Même pas, le serveur X ne gère toujours pas la redirection d'évènements il me semble. Enfin, pas officiellement. Après y'a une bidouille d'enfer dans Compiz pour gérer ça sur l'effet de zoom, je me demande bien comment ils ont fait d'ailleurs...
[^] # Re: Zarb
Posté par Sébastien TeRMiToR . Évalué à 1.
probleme qui est du a l'architecture de eax ou xxa mais de ce cote un nouvelle architecture de pilote arrive , c'est glucose.
Glucose est un port de xgl dans X (ca implique quelle changement dans les pilotes).
et la la composition original des premieres demo de xgl sans l'intermedaire d'un serveur X supplementaire, on pourrais avoir meme un début de support de cette archi dans xorg 7.4 (avec les pilotes intel)
[^] # Re: Zarb
Posté par Ph Husson (site web personnel) . Évalué à 1.
[^] # Re: Zarb
Posté par Pinaraf . Évalué à 2.
XAA, EXA et Glucose n'ont rien à voir avec le problème des applis 3D dans un environnement avec composite.
Cf http://dri.freedesktop.org/wiki/DirectRenderingToRedirectedW(...) si tu veux la doc officielle et http://bugs.freedesktop.org/show_bug.cgi?id=8732 pour le joli rapport de bug sur le sujet.
En ultra résumé : avec TTM, il sera "facile" de faire faire le rendu 3D d'une appli dans une texture en mémoire.
Puis pour info, avec Xgl ça marchait pas non plus.
[^] # Re: Zarb
Posté par Markov . É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...
[^] # Re: Zarb
Posté par Pinaraf . Évalué à 2.
Exa et glucose, on en a franchement rien à battre pour la transparence d'une fenêtre de nos jours. Des composite manager utilisant XRender, c'est devenu rare justement à cause du manque d'accélération. Glucose les mettra peut être à nouveau en avant, mais j'en doute.
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
Ils ne supportent pas le rendu accéléré pour des fenêtres redirigées avec Composite. Voilà, ma formulation précédente était peut-être pas claire. Les fbo on s'en fout pour ça.
[^] # Re: Zarb
Posté par Markov . Évalué à 1.
[^] # Re: Zarb
Posté par Pinaraf . Évalué à 2.
De plus les pilotes proprios nVidia utilisent ni XAA, ni EXA me semble-t-il, et ils accélèrent xrender...
[^] # Re: Zarb
Posté par Markov . Évalué à 1.
[^] # Re: Zarb
Posté par Pinaraf . Évalué à 2.
[^] # Re: Zarb
Posté par Le Pnume . Évalué à 1.
[^] # Re: Zarb
Posté par Le Pnume . Évalué à 1.
# Qt
Posté par jiyuu . Évalué à 1.
[http://vir.homelinux.org/blog/uploads/mirrors_everywhere.png]
[http://www.rzuser.uni-heidelberg.de/~mkretz2/crazy-buttons.m(...)]
[http://labs.trolltech.com/blogs/wp-content/uploads/2007/12/p(...)]
[^] # Re: Qt
Posté par Jean-Baptiste Mayer . Évalué à 1.
Merci beaucoup :)
[^] # Re: Qt
Posté par Narishma Jahar . Évalué à 1.
http://vir.homelinux.org/blog/index.php?/archives/89-going-c(...)
http://labs.trolltech.com/blogs/2007/12/19/q/
[^] # Re: Qt
Posté par Jean-Baptiste Mayer . Évalué à 1.
JB
# Sympa
Posté par François (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.