Raphael Junqueira a écrit 337 commentaires

En fait il y a une vraie solution:
Beos (oui le fameux) lorsqu'il creait une application graphique demarrait en fait deux threads:
- une de l'appli qui lancait le main
- une graphique

En gros tout l'affichage client etait gerer par la thread graphique et les 2 thread ne communiquent que par protocole de queues de messages.

Donc pour le parrallele avec kmail, quand tu clique sur un bouton et que la thread principale fait "d'enoooormes calculs" , la thread graphique envoie la notification du bouton presse a la thread principale (qui ne pouvant rien faire la, ne le traite pas de suite).
Si l'event de ce bouton est considere comme bloquant (le cas par defaullt mais on peut lui assigner un timeout), alors la thread graphique te marque le bouton comme enfonce mais continue a rafraichir l'affichage tout en ne t'empechant l'execution de toute "commande bloquante" (en clair pas mal de widgets grises,...)
Mais ce qui est genial c que par exemple si le widget multi-liste et text (si read-only) ne sont pas bloquants (je croit qu'ils ne le sont pas par defaut), tu peut continuer a lire tes mails tout en attendant que ta commande reponde (car c du simple affichage)

Cela est possible car c'est une thread graphique dans le contexte de l'application. Xfree ne pourrait pas vraiment le faire car il aurait besoins de bcp d'informations sur l'application (en clair ca ferait bcp trop de duplication de donnee). Ca serait plutot aux widgets Qt et Gtk de le faire mais il subissent les "stupides" limitations de XFree qui les empechent d'avoir un comportement similaire.

le probleme etant que la facon de penser interface 2d et moteur de rendu 3d sont tres differentes.
En clair un moteur de rendu 3d utilise optimialement les capacites de ta carte en utilisant beaucoup de textures (et optionnelement en appliquant des effets dessus) que l'on peut assimiler a des "rectangles" comme ceux utilises dans les "interfaces 2d" mais de plus permet d'avoir et de gerer nativement des informations qui font la gelere des interfaces pures 2d:
- en jouant avec le z-buffer 3d, tu peut gerer de facon ultra simple le recouvrement des fenetres par la carte 3d en full hardware (alors que l'algo 2d de la chose ne peut se faire qu'en semi hardware car tu ne peut filer toutes les infos a la cartes graphiques)
- avec les differents formats de textures supportees par les carte 3d tu n'a plus a faire de la conversion a la volee de definitions de rendu lorsque des applis utilisent differentes definitions en meme temps
- les bureaux virtuels ne deviennent plus que des zones de rendus a differentes positions dans l'espace (juste une translation pour changer de ws)
- plus reelement besoin de "hacks" a la overlay
- et enfin tous les effets "eye-candy" tordus qui trainent peuvent etre fait en pur hardware (ombres, blending selection souris, ...)

... pour ne plus avoir par exemple kmail tout blanc quand on envoie un gros message ...

tu va aimer alors :)
http://marc.theaimsgroup.com/?t=105077274100001&r=1&w=2(...)

Toi aussi :)

Tu les as un peu chercher en leur disant que tu utilisait une carte graphique de leut plus gros concurrent. Tu crois honnetement qu'ils allaient faire un effort pour supporter le concurrent. Encore tu aurait parler d'une s3 ou d'une matrox il auraient peut etre envisager la chose (en rigolant bien d'ailleurs) :)

Mais a part ca ils ont tjs ete bien reactifs si on leurs soumettaient des bugs reports digne de ce nom (j'en suis fort content d'ailleurs)

Bon
on va finir cette discussion sterile:

va donc faire un tour dans ce qu'on appelle le windows DDK (je sait c mal), surtout la partie HAL ddraw/d3d (qui correspond aussi a ce que doit implementer un driver de cg pour une couche optimale GLX/OpenGL) et tu va comprendre la complexite d'un driver de cartes graphiques (par rapport aux autres drivers d'autres peropheriques) surtout en tenant compte que bon nombre de fonctionnalites ne peuvent etre implementes (exemple: les textures compressees) sans utilisation de code tiers licence (suite de l'exemple: S3TC/DXTC, ...).

Maintenant pour les specs je ne voit rien qui empecherait la divulgation de celles-ci. Mais en etant honnete je ne verrait pas ce que l'on pourrait en faire a part avoir un tres bon support de la 2d.
Pour la 3d je pense que c'est bien illusoire de croire a une implementation libre performante sans l'aide de la centaine de devs specialises nvidia.

De plus il semblerait que certains devs xfree aient eut acces a un minimum de specs (surement sous NDA) car le driver nvidia libre marche tres bien en 2d (et ne croit pas qu'il marcherait si ils n'avaient pu avoir un minimum de specs)

Donc je serait le premier a feliciter nvidia si ils libereraient le code source d'un driver, meme sous-optimise, (je pense que ca nous apprendrait tellement) bien que je ne fasse pas trop d'illusions. Pour les specs j'attends tjs car ils doivent bien pouvoir sortir qquechose (en virant les qques petits morceaux de specs qui ne leurs appartiennent pas).

Maitenant au lieu de "taper" a chaque fois sur nvidia (avec un peu de raison), si vous pouviez mettre plutot votre energie a "taper" sur les fabricants de peripheriques beaucoup plus "simples" (et que les drivers ne contiennent vraiment aucun secret industriel) que ceux-ci ne prennent meme pas la peine de supporte sous linux ou filent (voire ne filent pas du tout) des specs totalememt minimalistes: support portables, certains modems, certaines imprimantes, ...

bouhhh c pas beau de parler sans laller voir la chose :)
http://keithp.com/cgi-bin/cvsweb/xcb/lib/XCB/(...)
j'aime bcp le style, c la premiere fois aue je voit du m4 pour generer du code :)

non ... texan (pas de bol pour lui)

arghhh
honte a toi :)

s/McCormack/Carmack/g


C'est le projet "Utah".

Utah-GLX, c bizarre selon le site il ne font pas beaucoup mention du driver NVIDIA mais surtout de la parti AGP du driver nvidia :(

ah si, je me souviens! C'est pas automake/autoconf??
c'est vrai qu'on fait difficilement plus incomprehensible!!

exactement :)

Nota: vous saviez que les premiers drivers officiels nVidia étaient distribués avec leurs sources, mais qu'elles été méchament modifiées pour les rendre inintellegibles? J'ai appris ça alors que je cherchais sur le net un projet de reverse engineering des drivers nVidia.

Ahh, d'ou tiens tu ca: liens ? liens vers le source ?

il est prévu pour la prochaine Debian

non ca sera la version 0.18 pour la debian, la 0.17 etant deja declaree trop "advanced" (ala JC) pour la future debian :))))

(bon, on a le droit de troller de temps en temps non ? :))

Juste de temps en temps alors, histoire de pas avoir trop de XP :)

jeune inocent,
tu as jamais vu du code m4 toi :))))

le code de XCB/XCL serait dans le cvs de e ? (pcque celui de e je sait bein recuperer)

comment on y accede au cvs ?

Oui il y a beaucoup à faire mais AMA, pour le passage du 2.0 au 2.2 ou du 2.2 au 2.4 la situation devait être similaire.

Ben de souvenir y avait vraiment pas autant de chose a finaliser pour les precendentes versions.
Enfin c comprehensible vu que du noyau 2.4 il en reste pas grand chose dans le 2.6 :)

Bien sûr tout dépend du matériel utilisié, etc...

C sur, moi vu mon materiel je vait eviter.

Donc selon moi il n'y a pas à s'inquiéter d'autant plus que le 2.6 n'est pas prévu pour un bon moment (je ne me souviens plus de la date prévisionnelle).

Je ne penses pas non plus, vu qu'ils partaient pour le Q4 2003.
Mais ca va faire long...

Ben il reste beaucoup a faire, deja faut qu'ils recuperent/integrent les correctifs eparpilles un peu sur tous les noyaux de devs.
Apres ils ont pas l'air d'etre sur de ce qui reste reelement comme probleme mais juste dont ils sont sur ca fait peur ...
En tout cas ca me jete un froid, je voulait l'essayer bientot

Petite precision, il faut savoir le code "OpenGL" de nvidia n'a plus grand chose a voir avec la version originale de SGI. Et que c'est surtout cette partie de leurs drivers qui porte le savoir faire de nvidia. Le reste n'etant que la communication avec la carte et la gestion du bus/de la memoire.

oui,
sauf que l'install/configuration de wine n'est pas encore tres user-friendly (et les plugins mozilla ca marche aussi avec wine normallement, mais bonne chance pour la conf).
Je passe regulierement pas mal de temps a la refaire apres une reinstall et crois moi ce que fait codeweavers c pas mal pour ca.

API: interface de programation, si tu reste API compatible cela veut dire que tu reste compatible source entre deux implementations differentes. Si tu change d'implementation il suffit alors de recompiler pour que ca remarche.

ABI: compatibilite binaire. Correspond a une compatibilite d'API avec en plus la garantie qu'a chaque nouvelle implementation ton binaire fonctionnera toujours. Cela n'etait pas trop le cas avec g++ qui produisait a chaque version (avant la 3.0) des binaires c++ qui n'etaient pas compatible avec les binaires compiles avec la version precedente. D'ou quand tu avait kde, il fallait tout recompiler kde+qt+fam+... pour que ca remarche.
Et maintenant vu que les compilos c++ partagent la meme ABI, tu peut avoir en parrallele des binaires compiles par icc avec des binaires g++ fonctionnant ensemble.

il y a pas besoin de winex ?

Non

Quels autres jeux marchent sous wine ?

De plus en plus, une grosse majorite des jeux d3d<8
a l'exception de ceux qui abusent de "l'overlay" et du multitexturing qui marchent assez mal (pas nombreux).
Mais c'est en cours de correction.
Pour les jeux d3d8+, la progression avait bcp ralenti depuis noel mais ca reprend: on est en voie de faire marcher des purs jeux d3d8 avec shaders.

au moins il est en rpm, c'est plus sympa à utiliser

De nombreuses distribs fournissent un wine rpm.

C'est plutot toi qui a mal interprete ce que je disait :)

Selon tes dires justes des projets que toi tu considere moteurs de LL meritent plus que d'autres.
J'aimerait savoir quels sont tes criteres qui te permettent de classer les LL dans cette categorie ?
Pacque par rapport a toi je ne considere pas le kernel Linux, ni gcc comme reelement des moteurs du libre. Il ne faut pas se leurer ce qui a construit et continue a construire une image positive du LL dans le monde des entreprises (et non des geeks) ce sont les nombreux LL tournant autour des protocoles/reseaux/securite: LDAP, apache, ...
Le kernel Linux commence a peine a percer et ne sera reelemenet utiliser quand il aura au moins autant de fonctionnalites que celui de windows (je pense que le 2.6 en aura bien plus)
Hors la majorite de ses applis qui reussissent ne sont pas "sponsorisees" par les grosses distributions qui elles favorisent les "grands projets" necessaires afin d'avoir une solution libre complete (ce qu'elles essayent de vendre)

Quand à dire que gcc et apaches sont de petits projets, il est certain que GNOME est un nain par comparaison, et KDE n'est pas un géant non plus, dans cette même comparaison.

On a pas la meme notion de grandeur alors. Regarde juste le nombres de developpeurs et la taille du code, tu verra que gnome n'est pas loin d'etre le plus gros projet sous GPL (il a pres du double de developpeurs que KDE).

Je te trouve un peu trop bloque.
En quoi peut tu dire qui ne "participe pas directement à GNU/Linux", leurs contributions sont dans wine en GPL.

veux tu dire que tout code GPL n'etant pas GNu-ifier ne doit pas etre considere comme appartenant a la mouvance libre ?
C'est avec toute ces petites choses que le libre finira par s'imposer. Regarde actuellement ce n'est pas linux, gnome/kde, etc ... qui construisent l'image du libre dans les entreprises mais plutot pleins de "beacoup plus petits" projets qui font de plus en plus parler d'eux: gcc, valgrind, apache, ...

ah pas assez rapide :)
tant pis g encore celle la:
http://www.winehq.com/?interview=4(...)

En gros wine etait sous une licence du type BSD.
Codeweavers depuis 5 ans contribuait a wine de facon libre (actuellement fournit le cvs, emploie le mainteneur, les principaux devs, ... cf JW http://www.winehq.com/?interview=4(...)).
A l'epoque de corel, les deux entreprises (corel et codeweavers) contribuaient d'egal a egal en partageant la gestion et leurs devs. Les deux possedaient un cvs perso qui servait de pre-integration dans le cvs officiel de wine.
Lorsque corel a arretee la branche linux, de nombreux devs de corel-linux (dont le chef du projet corel) se sont regroupes pour creer transgaming en voulant vendre la compatibilite dx sous linux.
Le probleme etant qu'ils ont voulus se "servir" dans wine en ne livrant de leur part qu'une partie de leurs efforts (tout directx sauf d3d qui est la part la plus interressante) ce que codeweaver a moyennement apprecie (sachant que eux rendaient toutes modifs dans le main tree).
Si on rajoute les differents "pseudo-forks" de lindows, etc... un "referendum" a ete fait entre tous les devvs et le choix de la GPL s'est impose. Cela a entraine que transgaming a forke la derniere version "BSD" de wine.

...je doute que rpm soit une norme comme tu le prétends,...

hmmm
http://www.linuxbase.org/(...)

Bon mis a part, l'aspect barbant et un peu "aggressif" du commentaire de feliciano, je ne pense pas qu'user de cette facon abusive des [-] soit l'ideal. Au pire juste qqu'uns mais la ....

Le seul interet de winex c pour le jeux pur (et encore).
Pour autre chose le wine officiel s'en tire nettement mieux (meme VB commence a marcher)
Pour le jeu ca progresse doucement mais surement dans la version officielle