Pinaraf a écrit 3671 commentaires

Dis moi, Bob il a quoi à foutre de l'arborescence de son système ?
Il a juste à connaître son dossier personnel, qui est accessible par l'icône maison.

Comment a fait le mec qui a son karma à 20 ? C'est impossible... Ou alors il n'a plus commenté depuis la mise en place de la limite du score des commentaires à -10/+10... (ha, le bon vieux temps des commentaires à +25...)

Je me demande à quel commentaire tu réponds là...
Il a pas parlé de Novell le mec hein. il a parlé de faits réels, du code... Certes, ça peut te paraître obscur comme concept.

Il a été ajouter à la version 1.1.0 qui est sortie il y a quelques jours.
Pipeau.
T'es même pas capable de lire un changelog.
Je vais être gentil, je vais te le traduire, peut-être le comprendras-tu, mais j'en doute :
- Ajout du support des RS600, support basique des RV670
- Support du panning dans RandR
- Support préliminaire (comprendre non testé) pour les connecteurs HDMI
- Compile avec le X.org version git
- Plein de corrections de bugs.


Mais bon, discuter avec toi c'est à peu près aussi intéressant que parler à un chat, sauf que le chat raconte pas de conneries pour combler son absence d'intelligence.

La numérotation des logiciels, particulièrement dans le monde du libre, suit une logique.
0.x : dév en cours, y'a des échafaudages un peu partout
1.0 : première version stable, tadam, attention peinture fraîche quand même.
etc...
Sinon à mon avis on aura un meilleur pilote libre nVidia qu'ATI d'ici 2009, parce que nouveau avance suffisamment vite. Actuellement nouveau bosse pas sur la 3D parce que ça n'a pas d'intérêt (comme pour tout autre nouveau pilote) grâce à/à cause de gallium. Mais ils savent déjà faire la base.
Le pilote nouveau actuellement est plus complet que le pilote radeonhd, et il supporte plus de cartes.

En libre, y'a le projet Looking Glass, openCroquet... https://lg3d.dev.java.net et http://www.opencroquet.org

Et KDE 4.1, t'en fais quoi ?

Ho putain, j'espère que c'est pas ça le troll de l'année... On n'est que le 3 janvier quand même, faut laisser du temps au temps.

T'es sous linux ? Utilise les bugs de l'applet flash : les fichiers mp3 sont enregistrés dans /tmp... sous dossier plugtmp ou un truc comme ça.

Heu, supertux ? Même pas, il utilise de l'OpenGL je crois... Et puis c'est support de la 2D sans accélération hein.

Ha désolé j'ai pas vu cette ligne dans ton merdier précédent, où tu as donc réussi à t'emmêler tout seul.

Faire un wrapper c'est gênant uniquement pour certains englués du cerveau dans ton genre qui ont toujours pas pigé que le soucis de KDE, c'est d'avoir une API/ABI stable pour une longue période (5 ans pour KDE 3.5), et ça, enchant et hunspell ne le garantissent pas. De plus, dans 5 ans hunspell passera peut être pour une grosse merde par rapport à <insérer ici le nom de la mort qui tue>. Bref, KDE voit sur le long termes, certains mollusques restent focalisés sur le court terme.

ce n'est pas quelques prototypes approximatifs qui vont les calmer
Hum, tu parles du pilote fglrx qu'on se farcit depuis des années là, ou du pilote radeonhd ? Remarque... ouais, les deux sont des prototypes, vu le niveau de stabilité de fglrx...

Pour croire qu'une premier version d'un driver écrit depuis 0 va être complet il faut vivre sur une autre planète.
Et pour la nommer 1.0 dès le départ faut faire du marketing.
La première version ça devrait être 0.1, pas 1.0.

Tu réinventes l'histoire du libre ?
Nan mais là je me demande quand est-ce-que tu situes ton "début du libre".
Le libre, c'est l'esprit d'UNIX à l'origine. Et c'était mieux que les autres OS non ?
Après certes ça a bifurqué, y'a eu des conneries à droite à gauche. Mais Stallman et GNU c'est 1983...

T'as fini de débiter tant de conneries ?

Pour info, phonon a déjà un backend windows, un backend OS X et 2 backends pour Linux. Dans l'ordre : DirectMedia, QuickTime, xine et gstreamer.
Ben oui, ils ont pas attendu qu'un crétin en parle sur linuxfr, ça a été fait. Bon, par contre je les ai pas testés, mais vu qu'il y a une bénédiction officielle par trolltech ça marchera pour la sortie de Qt 4.4


Sinon pour les histoires de dico avec Sonnet, ce qui est génial c'est que tu donnes toi même le baton pour te faire taper... http://fedoraproject.org/wiki/Releases/FeatureDictionary : "The newer KSpell2 API is plugin-based and uses libraries. It is what KDE 4's Sonnet is based on. KevinKofler backported Sonnet's enchant backend (kde#154560)."
En clair : pas de problème de ce côté là.


Mais la prochaine fois que tu veux jouer à madame irma, ouvre un skyblog.

Mais j'ai tord de chercher à t'expliquer ça.
Faisez gaffe hein, cherchez pas à parler à IsNotGood, il vit sur son nuage, dans son p'tit monde, bien au dessus de nos vies de merde !

Après bon, facile de taper sur nVidia... Y'a à peu près 8 ans (j'ai plus de liens par contre, j'avais encore des traces dans une archive de mailing list mais l'archive est plus dispo), ils se sont pris des avocats d'Intel et Microsoft au cul pour avoir sorti un pilote libre supportant la 3D pour les TNT et Geforce 1 de l'époque... Le pilote a été supprimé rapidement, le pilote nv a été obscurci et le pilote proprio nvidia est sorti. Après, pas étonnant qu'ils soient frileux.

Sinon le pilote radeonhd a été codé par Novell, ils ont fait une version 1.0 sauce marketing (en clair : inutilisable : pas de XVideo ni d'accélération 2D c'est à peine plus utilisable que vesa quasiment)

Les vrais programmeurs ils utilisent pas de noms de variable, ils utilisent directement les registres ou des adresses mémoire.

C'est mal barré pour le bordel avec EFI. Cf l'avis de Linus Torvalds sur le sujet
http://kerneltrap.org/node/6884

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

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

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.

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

Hein ?

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.

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.

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