Journal GTK+ et OpenGL pour bientot ??

Posté par  (site web personnel) .
Étiquettes : aucune
0
21
déc.
2007
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

  • # Zarb

    Posté par  . Évalué à 2.

    C'est quoi le lien entre utiliser OpenGL dans Gtk et faire des fenêtres transparentes ?
    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  . Évalué à 1.

      > C'est quoi le lien entre utiliser OpenGL dans Gtk et faire des fenêtres transparentes ?

      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  . Évalué à 2.

        > La redirection de rendu, c'est pour les trucs "tordus" type reflets, etc...

        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  . Évalué à 1.

      D'une part les drivers libre intel & radeon sont parfaitement capable de faire tourner un composite manager comme compiz. D'autre part les drivers libre intel supporte l'extension frame buffer object a laquel je pense tu fais reference. Donc: non nvidia n'est pas le seul a proposer cela dans sont driver.

      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  . Évalué à 3.

      Super, vu les commentaires, le commun des geeks (je parle même pas du commun des mortels) n'a toujours pas pigé le bordel X/Composite Manager/OpenGL/rendu direct/rendu indirect/Toolkit/Composite/Redirection/ARGB/...

      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  . Évalué à 1.

        > vous avez fumé quoi

        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  . Évalué à 2.

          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).
          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  (site web personnel) . Évalué à 2.


          Désolé d'être désagréable, mais tu fumes quoi ?

          Ho lui il prend des opiacés de temps à autre, mais là il est normal.


          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).

          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.


          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.

          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.

          NB : Je connais bien Direct3D (je développe avec) et je ne suis pas naïf dans ce domaine.

          Et moi je connais les bus assez bien (je les utilise tous les jours).

          • [^] # Re: Zarb

            Posté par  . Évalué à 2.

            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.
            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  . Évalué à 1.

        oui, mais ttm ne va pas changer le fond du probleme.
        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  . Évalué à 1.

        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  . Évalué à 2.

          Non la transparence n'est pas couteuse avec le protocole X car il n'est pas obligatoire d'utiliser Xrender. E17 se passe de XRender pour faire ses opérations de transparence par exemple (si on parle de transparence interne à la fenêtre), Compiz n'utilise que de l'OpenGL pour ça...
          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  . Évalué à 1.

            E17 utilise ses propres librairies pour le rendu, essaye la transparence sans e17 et sans acceleration (ni xaa ni exa) tu vas ressentir d'affreuses lenteurs.

            • [^] # Re: Zarb

              Posté par  . Évalué à 2.

              Ça prouve juste que ton affirmation comme quoi le protocole X est lent pour la transparence est fausse. D'ailleurs, c'est pas une question de protocole mais une question d'accélération.
              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  . Évalué à 1.

                Oui je me suis mal exprime ce n'est pas le protocol mais le serveur qui est lent pour ce genre d'operation. Ensuite XAA, EXA sont des architecture d'acceleration et tu cree ta propre architecture d'acceleration PlouPlouf si tu veux. NVidia implemente donc sa propre architecture, c'est leur choix et le resultat est plus que correcte.

                • [^] # Re: Zarb

                  Posté par  . Évalué à 2.

                  Excuse moi, j'ai cafouillé : je voulais dire que c'est pas une question de protocole mais une question d'implémentation. Une bonne implémentation logicielle pourrait être rapide (cf E17 par exemple, ils ont réussi leur coup niveau optimisation, mais un tel travail sur l'implémentation de Xrender dans le serveur X est-il possible aisément ?)

        • [^] # Re: Zarb

          Posté par  . Évalué à 1.

          Juste comme ça en passant- Si tu ne vas à tapis que si tu as le jeu max je veux bien de toi pour remplir mon aquarium ;-)

        • [^] # Re: Zarb

          Posté par  . Évalué à 1.

          Juste comme ça en passant- Si tu ne vas à tapis que si tu as le jeu max je veux bien de toi pour remplir mon aquarium ;-)

  • # Qt

    Posté par  . Évalué à 1.

    Tu parles de faire des trucs comme ça ou bien:

    [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(...)]

  • # Sympa

    Posté par  (site web personnel) . Évalué à 1.

    Je comprend rien a ce que vous dites, mais ils sont sympa les screenshots. Même si ça passe par la carte opengelized textured out of the box du X à la carte (l'addition svp) de ma lessiveuse du réseau locale de ma grand mère qui utilise Fedora parce qu'elle a bien compris que ubuntuCqu'UneMode.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.