Pinaraf a écrit 3682 commentaires

Des patchs en provenance d'apple.
Comme si apple fournissait des patchs tout fait.

C'est actuellement très difficile de backporter des modifications de webkit dans khtml si j'ai bien compris : les deux ont trop divergé...
Par contre pour KDE 4 avec le projet Unity ça pourrait changer.

Pour info, ça a toujours été comme ça : les mainteneurs des paquets ont accès en premier au code de KDE 3.5.5 pour que lors de la sortie de KDE 3.5.5 des paquets soient déjà dispos pour plusieurs distributions.

Il y a l'extension texture_from_pixmap, mais pas le support d'Aiglx...

Le gros problème pour KWin c'est que pour KDE 3.5, faut pas rêver : un tel changement, niet. Pour KDE4 par contre, ça sera bon... Mais faut patienter.

Souffrant de maux de tête ........


HEM
C'est plutôt blessé à la tête.

grub

Avec l'approche de Vista et son 1Go de RAM conseillé, tu vas vite voir la fin des machines fournies avec 256 Mo de RAM...

C'est pas bientôt fini les trolls sur la vitesse de Java ? Sortez des chiffres au moins !

Pour les performances de Looking Glass, ce n'est pas lié à Java mais plutôt à :
1- Nous et nos erreurs de programmation (je suis un contributeur du projet, je précise)... Exemple : on provoque de beaux memleak qui nous font garder en mémoire beaucoup de textures (c'est corrigé/en cours de correction dans le CVS là)
2- Java3D, mais ça s'améliore

Les différences de performances que l'on peut obtenir en corrigeant notre code montrent clairement que c'est pas la faute à Java...

Edgy n'accélère pas encore le boot. upstart n'a rien changé à la vitesse de démarrage pour l'instant.
Dans le futur ça changera, mais ça sera pour Edgy + 1.

Pour upstart, ça remplacerait cron/atd/anacron, inetd, l'init bien sûr, mais ça pourrait simplifier acpid, networkmanager... Par contre ça ne touche pas à udev.

Demande à Rasterman. Pour ma part, je pense qu'il parle du fait qu'il faille généralement des pilotes propriétaires, qui ont des problèmes de stabilité. Les pilotes libres en ont aussi d'ailleurs, il suffit de regarder un peu les mailing lists dri-devel.
Mais bon, je ne m'avancerai pas plus.

Xglx a un autre intérêt que tu ne mentionnes pas : il permet de tester la viabilité d'un serveur X qui fasse tout son rendu par l'OpenGL, et comme il partagera du code avec un éventuel Xegl, cela facilitera le développement de ce dernier. (Je suis assez pessimiste sur la possibilité de survie d'Xegl... Mais ce n'est pas le sujet).

Parce que bittorrent, c'est mieux :)

Tu n'as pas sorti le moindre argument. On met régulièrement le doigt sur la langue de bois des politiciens, mais apparemment celle de certains ici est bien chargée aussi.

Tu cliques sur Répondre pour dire un texte qui ne répond pas à mon commentaire. Quel est l'intérêt ?
De plus, relis moi : je n'apprécie guère Xgl. Ha oui, et aussi : les EFL c'est pas forcément de l'OpenGL parce que Rasterman préfère l'éviter. Mais c'est vrai, je connais pas.
J'attends de voir un Alt+Tab dans E17 qui affiche des miniatures mises à jour en live de fenêtres, incluant dans le tas une petite vidéo (dans un lecteur quelconque, qu'il s'agisse de Xine ou Mplayer, utilisant XVideo de préférence)

De même, tu tente de faire croire que X est propre et bien architecturé, ce qui est bien evidemment faux. Les EFL, si.
Démonstration ?

Tu confonds allègrement Xgl et X. C'est un piège facile qui s'est propagé avec le marketing de Novell.
Il est tout à fait possible de réaliser un composite manager utilisant l'openGl sans passer par la bidouille qu'est Xglx. Oui Xglx est une bidouille, je le sais et tout le monde devrait le savoir. Mais Xegl n'est pas une bidouille, et X.org avec aiglx non plus.
Pour info, un Composite manager utilisant l'OpenGL ça existe depuis au moins juin 2004, bien avant qu'on parle de Xgl. Et il gérait la vraie transparence, bien avant qu'on en parle dans E17 (vu qu'on n'en parle pas).

Au fait, les EFL c'est avant tout du rendu logiciel optimisé plutôt que du rendu OpenGL parce que Rasterman trouve l'OpenGL trop instable, ce en quoi il n'a pas forcément tord hélas...

Enfin, selon certains et des très sérieus tests de Rasterman.
Tests sérieux... Tu parles de son test avec son "wm torture" ?
Je l'ai testé. KWin 3.4 (je crois) contre Looking Glass l'été dernier. Sensiblement, l'utilisateur peut dire que Looking Glass consomme plus et est plus lourd que KWin. (Je l'affirme même... Il est particulièrement ardu de bosser sur ses performances. Bref passons).
Or avec le wm torture, Looking Glass est plus rapide que KWin. En effet, KWin dessine les fenêtres avant de les fermer alors que Looking Glass ne le fait pas... Les résultats sont donc faux, et je suis sûr que tous les résultats donnés par Rasterman ne prennent pas en compte ce paramètre.

De plus il n'a jamais présenté ça comme un benchmark (heureusement d'ailleurs)

Bien avant XGL, AIGLX, Compiz et tout les méchants hacks des codeurs X, les EFL était optimisé pour l'OpenGl et portait les ombres, les menus animées et la belle transparence.
Dis tu t'es renseigné un peu ?
Dire que le travail des développeurs de X c'est des hacks, c'est n'avoir rien compris au problème.
Les "ombres" dans E17, autour des fenêtres par exemple, c'est l'exemple parfait de la méthode "hack". Ces ombres sont dessinnées sur le bureau. Deux fenêtres se superposant n'auront pas d'ombres "d'une fenêtre à l'autre" (comme dit quelqu'un qui m'a posé la question... j'espère que sa formulation est claire, la mienne ne l'était pas).
La belle transparence, c'est aussi la même chose. Si tu déplaces un xterm sous un élément transparent dans E17, l'élément transparent n'affichera pas la fenêtre xterm. Ho si, il peut c'est vrai... la bonne vieille méthode des hacks avec les captures d'écran, super optimale. Essaye avec un contenu qui bouge comme une vidéo c'est mieux.
La seule méthode valable pour faire de la vraie transparence et des vraies ombres, elle passe par une extension dans X. Il n'y a pas d'autre solution. Il est irréaliste d'avoir chaque élément transparent du bureau qui fasse des captures d'écran de ce qu'il se passe derrière lui toutes les x millisecondes. Il doit être notifié des modifications, et modifier son affichage en fonction de ces modifications.

J'ai jamais dit que tu as dit que c'était la solution non plus, merci de ne pas me faire dire ce que je n'ai pas dit que tu as dit. :)

Avec les pilotes alsa 1.0.13rc1 c'est pas mieux hélas...

acpi=off c'est une solution pour un portable ?
L'un des objectifs après c'est d'avoir une veille fonctionnelle, donc en acpi=off c'est filochon...
Merci pour l'info sur alsa, on va essayer dès que possible.

Avec Edgy c'est pas mieux... Et vu les difficultés rencontrées avec Edgy (maintenant qu'il y a eu le freeze ça devrait aller mieux), on a changé pour debian.

(Je sais c'est pas moi l'auteur du post mais en fait c'est un pote... et je pense que c'est plus pratique pour lui qu'il suive son problème)

Comme dit l'autre, t'as pas du tester.
Voici un exemple simple : http://bugs.kde.org/show_bug.cgi?id=122803

Dans OpenOffice Impress, créer une présentation vierge. La première page est en mode plan. Tu supprimes les puces, et tu enregistres. Tu ouvres dans KPresenter : les puces sont présentes.
Les développeurs de KOffice ne peuvent rien faire : OpenOffice ne respecte même pas la DTD du format OpenDocument sur le coup.

Désolé, ça a en effet disparu des accords. Peut être lors du s/MSN/Live/..
(J'ai autre chose à foutre que vérifier toutes les semaines les éventuels changements dans un accord que je refuse)