Glow 0.1 est la première mouture publique du collecticiel client de OOo, sortie le 7 juin 2003.
Licence : LGPL/SISSL
Langage : 100 % java
Ci-dessous, lien vers d'autre groupiciels
NdM : le groupe s'appelle OOogw pour faire simple. L'outil se base sur XML, et le développement collabore avec Mozilla Calendar et PHPGroupWare. Colm Smyth dans son courriel sur le groupe openoffice.groupware.dev du 7 juin 2003 :
-espère sortir au cours de ce mois, un serveur de calendrier (ou régeste ?) publique (WCAP)
-appel aux rapports de bogue, suggestions, code
-espère que des développeurs et/ou entreprises apportent leur aide
-attend développeurs et/ou entreprises pour travailler sur la section (non développées pour le moment) courrielleur, messagerie instantanée, gestion de fichiers avec support de Webdav.
collecticiel n. m.
Logiciel qui permet à des utilisateurs reliés par un réseau de travailler en collaboration sur un même projet.
synonyme(s) : synergiciel n. m., groupiciel n. m.
source : gdm, granddictionnaire.com
Autre liens de collectitiels (yavaitplusdeplace) :
Kroupware (GNU/GPL)
http://pim.kde.org/development/kroupware.php
Ximian Evolution (GNU/GPL) + Connector (module proprio de connection à MS Exchange )
http://ximian.com/products/evolution/
http://ximian.com/products/connector/
phpGroupWare (GNU/GPL)
http://www.phpgroupware.org/
Si vous avez d'autre liens et des commentaires sur les collectiels que vous avez pu rencontrer et/ou installer : lachez-vous ! :)
(Précisez bien si ce sont des clients ou des serveurs ou les deux. NdM : en client lourd ou léger/web et puis la licence)
Aller plus loin
- Glow - client collecticiel du groupe Ooo (10 clics)
- Projet collecticiel de OpenOffice.org (2 clics)
- OSAF (GNU/GPL) (0 clic)
- Minkowsky client-serveur (GNU/GPL) (1 clic)
- TWIG (GNU/GPL) (2 clics)
- Skriv (GNU/GPL) (2 clics)
# Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par kesako . Évalué à 3.
Ouch ! deja que 00 ce n'est pas leger leger, si en plus on rajoute java , ca va exploser !
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par superpop . Évalué à -7.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Sami Dalouche . Évalué à 1.
pourquoi ne pas faire du java avec bindings gtk/gnome ? ou meme swt a la limite, ca sera toujours mieux que swing....
enfin bon, il faut se dire que des framework vont etre constuits, ca parle de serveur de calendriers, etc, ensuite ca donnera envie aux gens de programmer des trucs propres (gnome, kde)
sam
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Olivier MARTIN . Évalué à 3.
Mais pourquoi n'ont il pas employé de meme framework de composant que celui utiliser par OO?
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par mrlem (site web personnel) . Évalué à 1.
Sur le long terme c'est à voir... Il me semble me rappeler que pour le JDK 1.5 les interfaces Swing pourrait prendre avantage de l'interface native (et plus seulement utiliser un look and feel ressemblant).
Dans ce cas, il faudra voir ce que çà donne, mais çà peut être judicieux de ne pas s'engager dans un autre toolkit... tout de suite.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Christophe GRAND (site web personnel) . Évalué à 4.
Dans ce cas, il faudra voir ce que çà donne, mais çà peut être judicieux de ne pas s'engager dans un autre toolkit... tout de suite.
D'un autre point de vu sur le long terme, en misant sur une évolution du JDK1.5 tu t'inscris encore plus dans une relation de dépendance vis-à-vis de Sun et comme c'est pas de si tôt que l'on aura un JDK1.4 ou + libre...
Sur le long terme c'est la solution faisant intervenir le plus de solutions libres|ouvertes qui gagne.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Thomas MARTIN (site web personnel) . Évalué à 7.
# quel est le con qui a trouvé collecticiel ?
Posté par modr12 . Évalué à 2.
ok je sors
[^] # Re: quel est le con qui a trouvé collecticiel ?
Posté par gilles renault (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: quel est le con qui a trouvé collecticiel ?
Posté par redguts . Évalué à 1.
non, ça fait penser à un gratte-ciel mal lavé
groupociel?
non, ça ne sonne pas bien
bandaciel?
euh... faut pas avoir l'esprit mal tourné
meutociel?
nan : trop 'zyva'
polyciel?
ah ouais, j'aime bien
[^] # Re: quel est le con qui a trouvé collecticiel ?
Posté par Glenn Y. R. (site web personnel, Mastodon) . Évalué à 7.
[^] # Re: quel est le con qui a trouvé collecticiel ?
Posté par zyglotron . Évalué à 7.
Et pourquoi pas de synerciel ou synergiciel, c'est censé générer de la synergie ce genre de logiciel :o)
"On a du redémarrer la centrale synergicielle" ça fait bien accompagné d'un "J'ai réazimuté le zyglotron" quand le client vous demande ce qui n'allait pas :o)
[^] # Re: quel est le con qui a trouvé collecticiel ?
Posté par Anonyme . Évalué à 2.
[-1] ce monde est sans pitié
[^] # Re: quel est le con qui a trouvé collecticiel ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: quel est le con qui a trouvé collecticiel ?
Posté par zyglotron . Évalué à 1.
[^] # Re: quel est le con qui a trouvé collecticiel ?
Posté par Gniarf . Évalué à 2.
[^] # Re: quel est le con qui a trouvé collecticiel ?
Posté par Jeff . Évalué à 1.
# Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Sébastien Lardière (site web personnel) . Évalué à 10.
Allez, quelques srishoutes : http://seb.ouvaton.org/tmp/(...)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par dinomasque . Évalué à 3.
BeOS le faisait il y a 20 ans !
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 2.
Je suppose qu'ils ont repris des parties que Sun avait programmées / rachetées de Star.
C'est pour moi le signe que je vais pouvoir me séparer de Star Office que je n'ai gardé qu'à cause de la gestion des rdv. que j'utilisais.
# Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par dinomasque . Évalué à 3.
"Work with the right technologies - use Java:"
LA ou ça devient intéressant c'est quand on voit que la "bonne technologie" n'a strictement rien à voir avec OOo.
Donc Glow n'a rien à voir avec OOo, ca sera juste un bidule lourdingue (Java oblige) et mal intégré.
BeOS le faisait il y a 20 ans !
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à 2.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 6.
Le problème est que OOo est un bureau ! Il suffit de rajouter un gestionnaire de fenêtre, et tu as un environnement bureautique complet, avec client mail et navigateur internet.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Adrien . Évalué à 3.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Nÿco (site web personnel) . Évalué à 0.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à 1.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Nÿco (site web personnel) . Évalué à 3.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Erwan . Évalué à 1.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Il y a au moins un point commun : Le copyright SUN. C'est donc un truc qui sera à priori intégré à StarOffice, avec une jolie boite à la FNAC, un installeur commun avec OOo ou SO, ... Un argument de moins pour "OO, c'est null, y'a pas d'agenda, alors qu'avec MSOffice, y'en a un", ...
Techniquement, je ne sais pas si ça apportera grand chose, mais au niveau marketing, c'est une bonne chose.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par modr12 . Évalué à -1.
# D'autres collecticiels
Posté par Emmanuel Seyman . Évalué à 10.
Serveur Exchange sous Linux écrit en Python. GPL mais le module client est payant.
Direto: http://www.direto.org.br/(...)
Aucune idée (le site est en protugais)
Desknow: http://www.desknow.com/(...)
Serveur de communication proprio. La version normale est gratuite, la version pro payante.
Mimerdesk: http://www.mimerdesk.org/(...)
Groupware passant par une interface web. Ecrit en Perl sous GPL
PHPProjekt: http://www.phprojekt.com/(...)
Groupware web écrit en PHP. GPL
MoreGroupware: http://moregroupware.sourceforge.net/(...)
Tout pareil, Web, PHP, GPL
Group-Office: http://www.hilckmanngroep.com/sourceforge/(...)
Idem.
Samsung Contact: http://www.samsungcontact.com/en/(...)
Clone Exchange tournant sous Linux. Proprio, payant.
phpGroupWare: http://www.phpgroupware.org/(...)
Groupware web écrit en PHP. GPL
[^] # Re: D'autres collecticiels
Posté par Gonéri Le Bouder (Mastodon) . Évalué à 5.
http://kroupware.kde.org(...)
Il est prévu une intergration de kmail, kaddressbook, knode, etc
Des captures d'écran
http://kroupware.kde.org/screenshots.html(...)
Et la faq
http://kroupware.kde.org/faq/faq.html(...)
[^] # Re: D'autres collecticiels
Posté par vga1523 . Évalué à 1.
je suppose que tout ceci cera intégré à kde 3.2 ??
qui d'autre à testé ?
est il possible de synchroniser le sony ericson p800 avec un groupware du type kolab ou phpgroupware ?
[^] # Re: D'autres collecticiels
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Mais vu que c'est compatible exchange, ne pourrais-t-on pas utiliser Evolution ? (malgré son épaisseur ;) )
[^] # Re: D'autres collecticiels
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: D'autres collecticiels
Posté par free2.org . Évalué à 1.
[^] # Re: D'autres collecticiels
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: D'autres collecticiels
Posté par free2.org . Évalué à 1.
la question suivante est: est-ce que le serveur exchange GPL est compatible avec des standards comme smtp, ical, etc. auquel cas il peut peut-etre communiquer à la fois avec des clients GPL smtp/ical et des clients propriétaires de type Exchange
ce serait une solution + économique que d'acheter le Ximian Connector non libre
[^] # Re: D'autres collecticiels
Posté par Psychofox (Mastodon) . Évalué à 1.
You can download the exchange4linux Outlook(TM) Connector for Outlook 97 - 2000 by http at the following site:
exchange4linux-outlook2000-setup-2.3.10.exe (MAY-30-2003)
You can download the exchange4linux Outlook(TM) Connector for Outlook XP by http at the following site:
exchange4linux-outlookxp-setup-2.3.10.exe (MAY-30-2003)
Le client c'est outlook :
N&H received more and more customer requests asking for a independent workgroup server solution running under LINUX, but using MS-Outook(TM) as the Client on the MS-Windows(TM) Desktop for use with shared calendars and task lists, etc, and not limited to e-mail. MS-Outlook(TM) uses a MAPI Service Provider to store workgroup data centrally in MS-Exchange(TM) database or other 3rd party messaging servers.
s'il faut déja un connector pour pouvoir utiliser outlook, ça risque d'être dur d'utiliser evolution. En fait, c'est juste une solution pour les boites qui veulent un serveur exchange à pour moins cher.
[^] # Re: D'autres collecticiels
Posté par Rozé Étienne . Évalué à 1.
(http://www.plone.org/(...) ) Je n'est pas testé...
Tous ces liens donnés sont certainement intéressant. Mais est-ce que quelqu'un connaitrait un document ou un site qui comparerait ces logiciels et leurs fonctionnalités. Il faudra que je le fasse mais si c'est déjà fait...
[^] # Re: D'autres collecticiels
Posté par matli . Évalué à 1.
[^] # Re: D'autres collecticiels
Posté par Jeff . Évalué à 2.
# Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par arnaud . Évalué à 2.
2 'f' a Office
# Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
java n'est pas lent ! ca dépend de comment on programme !
Pour preuve :
http://arkanae.tuxfamily.org/fr/index.html(...)
http://www.eclipse.org(...)
http://about.me/straumat
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à 2.
Pour preuve : Frozen Bubble.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à 2.
Ceci étant, par dela le ridicule total de cette comparaison, je ne vois pas le problème. Il est logique d'implémenter d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces. La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu, contrairement à OpenGL for Java. SWT d'IBM est déjà beaucoup mieux.
C'est amusant comme quand tu parles de Java tu perds toute crédibilité et pertinence.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à 0.
Ah, les sprites FB sont affichés pixel par pixel en "100% pur Java", peut-être ? Il n'y a pas la moindre bibliothèque en-dessous ? Je suis scié.
Et c'est sûr que le rendu graphique de Frozen Bubble est comparable à celui de Arkanae.
On s'en fout, puisque le rendu graphique est effectué par une lib en natif. Ce qui compte, c'est le moteur de jeu.
Du reste au vu des screenshots l'environnement 3D d'Arkanae est extrêmement pauvre vis-à-vis de ce qui se fait dans le genre dans le domaine commercial. M'enfin, chacun son truc.
La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu
C'est sûr qu'en posant comme hypothèse la conclusion à laquelle on veut arriver, y a pas trop de mal à la démontrer :-))
C'est amusant qu'apparemment tu ne penses pas à faire le même raisonnement pour les autres langages. C'est une incapacité à comprendre la relativité d'un argument ?
Il est logique d'implémenter d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces.
Pourquoi Java au lieu de Perl ou C++ ? Il ne me semble pas que Java ait des qualités qui en fassent le langage idéal pour la programmation d'interfaces graphiques.
Il n'y a rien de "logique" là-dedans, c'est simplement que tu aimes Java. Un amateur de Python ou Ocaml te sortira la même phrase au mot près, mais avec Python ou Ocaml à la place de Java. Et il aura aussi raison que toi.
C'est amusant comme quand tu parles de Java tu perds toute crédibilité et pertinence.
Là pour le coup question pertinence tu fais très fort :)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Keos . Évalué à 3.
C'est vrai que Swing est affreusement lent...mais je pense que ce que BouBou voilais dire c'est que Java c'est bien pratique quand il faut faire du cross platform...il est clair que comme OpenOffice est dispo sur +sieurs platform, glow doit l'etre aussi....alors oui on peux faire du cross platform en C++ ( il est pour neuneu celui la au fait ??? nan juste pour savoir, j'ai un peu de mal) mais c'est souvent aussi lait que le langage lui-meme ( meme RMS le dit ;)...et puis OpenOffice quel belle exemple de _SUPER_RAPIDITE_(tm) ;)
Sa me gave de voir que dans une communauté qui se veut ouverte on assiste a de telle fermeture d'esprit....m'enfin
Les gas faut arréter, vous devenez aussi binaire que vos machine....
(Suze c mal, login c mal, Java c mal tm)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Keos . Évalué à 0.
/s lait laid
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à 0.
je me souvient d'une phrase genre "VB ou Java, enfin un langage de neuneu quoi"
J'ai dit ça ? Je devais être dans un grand jour :-))
Ceci dit, et tout troll mis à part, les interfaces graphiques réalisées en Visual Basic répondent en général bien mieux que celles faites en Java. (et pour appeler des routines externes, VB s'interface naturellement avec COM)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Keos . Évalué à 0.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à 1.
Tu es vraiment d'une mauvaise foi consternante. Tu sais très bien que seul le C affiche les pixels de façon directe, et encore, la plupart des drivers contiennent de l'assembleur. D'autre part, tu sembles oublier (ou ne pas connaître) plusieurs choses.
D'abord, Frozen Bubble version Java est écrit en AWT pour être compatible avec java 1.1. Les sprites sont gérés avec drawImage, qui était l'api de plus bas niveau en Java (ce n'est plus cas avec les versions récentes). L'appel Java est traduit en un appel natif de la bibliothèque graphique sur laquelle AWT est construit (par exemple Motif sous Unix). Il n'y a donc pas de différence notoire entre un programme Java et un programme C utilisant motif. Et les performances de FB en Java prouvent qu'on peut très bien faire de l'utilisable avec la version 1.1 en Java pur, tout aussi pur que n'importe quel programme dont l'affichage est géré par X11 (ou d'ailleurs par windows, ça revient au même). Il existe très peu de toolkits qui parlent directement le protocole X, par exemple. Ils utilisent en général la XLib.
D'autre part, il existe depuis la version 1.4 de Java une api d'accès direct à la mémoire vidéo qui permet d'être encore plus pur Java, puisqu'on court-circuite le toolkit.
Enfin, SDL, la bibliothèque C sur laquelle est basée FrozenBubble en Perl est destinée à la programmation de jeu. Le blitting des sprites est écrit en assembleur, par exemple. Trouver là dedans une preuve des performances de Perl est bien sur ridicule (ce que tu ne sembles pas nier), mais voir qu'on peut faire aussi bien en Java sans passer par une optimisation de très bas niveau, prouve effectivement que Java fonctionne correctement.
On s'en fout, puisque le rendu graphique est effectué par une lib en natif. Ce qui compte, c'est le moteur de jeu.
Absolument pas, cf supra. SDL est une super bibliothèque très optimisée qui est interfacée correctement avec Perl, d'où de bonnes performances. Mais on peut faire aussi jouable en Java sans assembleur, sans accès direct à la mémoire vidéo, etc. De même, OpenGL est super optimisé et remarquablement bien interfacée avec Java, ce qui permet de programmer objet tout en obtenant d'excellentes performances. Peut-on faire ça en Perl avec un rendu aussi complexe que celui d'arkanae ?
Du reste au vu des screenshots l'environnement 3D d'Arkanae est extrêmement pauvre vis-à-vis de ce qui se fait dans le genre dans le domaine commercial.
Et alors ? C'est quoi le rapport avec la choucroute à par dénigrer gratuitement le travail des autres ? Le rendu d'arkanae est plus complexe que celui de Frozen Bubble, qu'il soit inférieur à celui de Doom III ne change rien à ça.
C'est sûr qu'en posant comme hypothèse la conclusion à laquelle on veut arriver, y a pas trop de mal à la démontrer :-))
C'est amusant qu'apparemment tu ne penses pas à faire le même raisonnement pour les autres langages. C'est une incapacité à comprendre la relativité d'un argument ?
Où est-ce que tu vois que je ne fais pas le raisonnement pour les autres langages ? De très nombreux langages ont choisis de se baser sur gtk avec des performances excellentes. De même, les performances de swt en Java sont très bonnes. J'en déduis donc que le probème de swing n'est pas Java, mais swing. Si tu ne comprends pas, je n'y peux rien.
Pourquoi Java au lieu de Perl ou C++ ? Il ne me semble pas que Java ait des qualités qui en fassent le langage idéal pour la programmation d'interfaces graphiques.
Je n'ai jamais dit ça, bien que une non relecture de ma phrase ait provoqué l'apparition d'un mot inutile (implémenter). Je voulais dire "il est logique d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces.", ce qui n'a aucun rapport avec les interfaces graphiques, mais la réutilisation de ce qui se fait de bien. Sinon, je ne considère pas Perl comme un langage de haut niveau.
Il n'y a rien de "logique" là-dedans, c'est simplement que tu aimes Java. Un amateur de Python ou Ocaml te sortira la même phrase au mot près, mais avec Python ou Ocaml à la place de Java. Et il aura aussi raison que toi.
Pour l'aspect logique, cf plus haut. Sinon, oui, Python et Ocaml sont d'excellents langages qui sont interfacés avec des bibliothèques efficaces en C. Et alors ?
Là pour le coup question pertinence tu fais très fort :)
En tout cas, je n'atteinds pas ton niveau de mauvaise foi.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à -1.
Alors ça veut dire quoi "100% pur Java" dans ta phrase d'origine ?
Tu reconnais finalement avoir dit des âneries, c'est bien ;)
Enfin, SDL, la bibliothèque C sur laquelle est basée FrozenBubble en Perl est destinée à la programmation de jeu. Le blitting des sprites est écrit en assembleur, par exemple.
Que vient faire la méthode d'implémentation des bibliothèques natives dans une discussion sur les langages compilés en bytecode ?
Trouver là dedans une preuve des performances de Perl est bien sur ridicule
Oui. Et trouver dans Arkanae une preuve des performances de Java est ridicule. Tu comprends l'analogie ou il te manque encore un bout d'objectivité pour accepter l'évidence ?
C'est quoi le rapport avec la choucroute à par dénigrer gratuitement le travail des autres
Oh rien, je ne fais que sous-entendre que manipuler quelques dizaines de triangles simultanés ne doit pas être trop lourd pour une machine moderne, même avec un langage poussif... Et comme la complexité graphique du rendu (texturages, etc.) est dévolue à OpenGL ou à l'accélération matérielle, cela ne rentre de toute façon pas en ligne de compte dans le travail dévolu à Java.
Le rendu d'arkanae est plus complexe que celui de Frozen Bubble
Sans définition de la "complexité" d'un rendu cela ne veut pas dire grand'chose de chercher à comparer 2D et 3D. Et puis, après avoir convenu toi-même que le rendu ne faisait pas partie du langage hôte (puisque réalisé par des bibliothèques natives), tu persistes avec cet argument idiot. Mais bon, si ça peut te permettre d'évacuer un excédent de fougue :)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à -1.
Ca veut dire que le programme est écrit entièrement en Java et utilise un toolkit écrit en C. Tu es stupide ou tu le fais exprès ? Tu ne vois pas la différence avec SDL qui propose une api pour les jeux, avec gestion des sprites, etc ? Et donc qu'il y a beaucoup plus de C dans Frozen Bubble Perl que dans la version Java ?
Que vient faire la méthode d'implémentation des bibliothèques natives dans une discussion sur les langages compilés en bytecode ?
Ca commence a devenir clair dans ma tête, tu le fais exprès... Mais comme je suis charitable, je t'explique : si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Oui. Et trouver dans Arkanae une preuve des performances de Java est ridicule. Tu comprends l'analogie ou il te manque encore un bout d'objectivité pour accepter l'évidence ?
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame. Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances. Mais visiblement, tu ne veux pas comprendre, alors bon...
après avoir convenu toi-même que le rendu ne faisait pas partie du langage hôte (puisque réalisé par des bibliothèques natives), tu persistes avec cet argument idiot
Mais tu es vraiment crétin, c'est ça ? Aucun langage autre que le C (et encore), n'utilise le hardware moderne de façon native. Tu es trop bête pour comprendre ça, c'est ça ton problème ? Les drivers sont programmés en C et en assembleur, puis on ajoute une couche du langage cible. C'est la vie.
Actuellement, l'impression de lenteur associée à Java est presque exclusivement liée à trois choses : l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage) qui donne l'impression que ça rame sur une machine avec une mémoire sous dimensionnée, le temps de chargement (lié au fait que Sun n'a toujours par prévu la sauvegarde du code byte compilé pour les bibliothèques de base) et surtout swing. Nous sommes plusieurs a essayer de t'expliquer que swing pose problème, pas Java, avec des exemples de couches d'abstraction mieux conçues comme SWT ou comme Open GL for Java. Mais comme tu te comportes comme un crétin, tu ne veux pas comprendre. J'abandonne.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à -1.
Non, je ne vois pas la différence, puisque conceptuellement il n'y en a aucune.
Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Donc tu es train de me dire que si la bibliothèque utilisée est mal programmée, les performances du langage qui appellent la bibliothèque sont plus importantes que si la bibliothèque est bien écrite (en toute logique, c'est l'inverse puisqu'il y a moins d'overhead) ? Tu n'as pas l'impression de raconter n'importe quoi ?
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie. Heureusement que tu finis tous tes messages en disant que tes interlocuteurs sont de mauvaise foi :-)
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame
C'est marrant : pour une fois que je ne dis pas cela, tu te mets en tête de le réfuter. C'est une obsession chez toi ?
Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Mais tu es vraiment crétin, c'est ça ?
Je ne veux pas t'imiter dans l'insulte, mais j'impression que c'est toi qui est trop crétin pour comprendre que :
- je suis d'accord depuis le début que les primitives graphiques sont codées en natif
- c'est précisément l'argument que j'employais pour dire que le "rendu complexe" (je rigole doucement) d'Arkanae ne prouvait rien quant aux performances de Java
l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage)
Voici une URL intéressante :
http://internalmemos.com/memos/memodetails.php?memo_id=1321(...)
C'est supposément un mémo interne Sun Microsystems. Voici un passage qui concerne l'occupation mémoire de Java (les chiffres sont crédibles et restent à peu près valables à mon avis) :
« Given this data, it appears that the JRE can actually be simpler than the Python RE since Java does at least some of this work at compile time. The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.
Further examples of what is possible include the compiling OO languages Eiffel and Sather which fit their garbage collector, exception processor and other infrastructure into roughly 400K of resident set. While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. This seems to indicate that the resident set requirements of the JRE could be reduced by at least 80%. »
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à -1.
Quand tu sous-traites quelque chose (par exemple l'affichage) à un ebibliothèque implémentée en C et en assembleur, celle-ci est destinée à te faire gagner du temps (ça va, tu as compris jusqu'ici ?). Plus la bibliothèque est bien faite, plus elle te fait gagner du temps (exemple, en SDL tu peux demander à la bibliothèque de bouger un sprite, le tout implémenté en C et en assembleur) (tu suis toujours ?). De ce fait, avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage (pas de problème ? Je peux répéter, si tu veux). Donc, meilleure est la bibliothèque (en C), moins les performances de l'autre langage influent sur les performances globales. Normalement, tu devrais comprendre, maintenant.
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie.
Ca me semble cohérent, quel est le problème ? Je vais préciser, parce que tu sembles en mauvaise forme ce soir. Swing est une couche 100% Java ajoutée par dessus le toolkit de la plateforme cible. Il ne bénéficie que très peu du dit toolkit (sous linux en tout cas) car presque tout est ré-implémenté (ascenceur, gestion du focus, etc.). De plus, il y a des problèmes dans la gestion des pipelines graphiques, quelques erreurs de conception (reconnues par Sun et en cours de correction) etc. Bref, ça rame, tout le monde est d'accord. Le concurrent SWT d'IBM ne rame pas. Il n'est pas aussi réactif qu'une interface en C, je suis d'accord, mais il est tout à fait utilisable, même sous linux. Ca prouve qu'on peut faire un toolkit Java correct. Qu'il soit basé sur du C ne pose aucun problème, c'est le cas de tous les langages. Enfin, AWT n'est pas génial pour faire des jeux, car même s'il rame moins que swing (il y a une couche en moins), il est très loin d'offrir les fonctionnalités évoluées de la SDL. Il est donc remarquable (au sens de notable, pas au sens de formidable) que Frozen Bubble fonctionne bien malgré l'utilisation de l'AWT.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Fais un effort, je pense que c'est à ton niveau.
Je ne veux pas t'imiter dans l'insulte
Quelques exemples (c'est moi qui souligne) :
C'est une incapacité à comprendre la relativité d'un argument ?
Tu reconnais finalement avoir dit des âneries, c'est bien ;)
tu persistes avec cet argument idiot
Quant à ton memo, il est amusant. Evaluer l'empreinte mémoire avec HelloWorld, c'est sur puissant. Comparer un langage comme Sather dont le support du parallelisme très limité (par rapport à Java) et dont l'aspect dynamique est inexistant à Java est aussi tout à fait fair play et de bonne foi (pareil pour Eiffel sur l'aspect dynamique). Pour la comparaison avec Python, je ne me prononce pas, je ne connais pas assez bien trois choses : la part des bibliothèques qui sont écrites en C (ce qui limite toujours l'occupation mémoire), l'aspect multi-thread et le niveau de reflexivité/introspection.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à -1.
Non, n'importe quoi. Si l'overhead apporté par la bibliothèque est moins important, alors l'influence du reste est plus importante relativement au total (c'est des maths, tu sais). Et puis, apprends à lire les messages auxquels tu réponds, tu t'enfonces dans un argumentaire qui vient d'être réfuté pour la troisième fois. Pas que je me lasse...
Evaluer l'empreinte mémoire avec HelloWorld, c'est sur puissant
Oh, ils ne parlent pas que de ça, il suffit de savoir lire. Et puis, HelloWorld permet justement de mesurer l'overhead minimal (coût fixe) de l'environnement d'exécution. Mais bon, tout ça, c'est trop compliqué, d'ailleurs "Java rulez dans l'embarqué" et "la mémoire a un coût dérisoire, quelle importance si ça en bouffe beaucoup" (sic) n'est-ce pas :-))
Quelques exemples (c'est moi qui souligne) :
Tu ne sembles pas comprendre la différence entre dire qu'un argument est "idiot" (ce qui se conçoit rationnellement) et dire qu'une personne est "crétine" (ce qui est de l'ordre de l'appréciation subjective et du dénigrement de bas étage). Je m'en fiche un peu, c'est juste que ça ne rend pas tes interventions très crédibles...
Enfin, bon, ton gros problème est que tu t'es engouffré bille en tête dans une discussion à laquelle tu n'as rien compris mais où il te semblait scandaleux qu'on critiquât Java, n'est-ce pas ? Ayant dû abdiquer le débat sur les jeux video où tu t'es fait ramasser par plusieurs personnes à cause de ton manque chronique de connaissances en la matière, tu es maintenant réduit à lancer des attaques personnelles et à ressasser quelques arguments déjà plusieurs fois réfutés ;)
Same player, shoot again ?
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à -1.
Tu confonds évaluation théorique et réalité pratique, ce qui est très génant pour un jeu. Ce que l'utilisateur voit, c'est la fluidité du jeu, en gros le nombre de frame par seconde. Quand ça tombe en dessous d'un certain niveau, c'est injouable. A partir d'un autre niveau, on ne voit plus la différence. Entre 150 fps et 50 fps (en valeur minimale), pour un jeu comme frozen bubble, il est impossible de faire la différence. Si ta bibliothèque C est bien faite, comme c'est le cas de SDL, tu peux facilement dépasser très largement le minimum syndical. Que le reste de l'application rame un peu ne change pas grand chose car cela représente une part infime des performances de la dite appli. Tu as parfaitement raison de dire que l'influence relative du langage est plus importante quand la bibliothèque est bien faite, mais on s'en fout. L'importance relative n'est pas directement perçu par l'utilisateur, c'est la réactivité de l'ensemble qui compte. Quand tu programmes avec une bibliothèque comme SDL ou OpenGL qui te permets de garantir (ou presque) de bonnes performances, le reste importe peu. A contrario, quand tu utilises une bibliothèque mal faite, il te reste une part très faible du temps CPU disponible entre deux frames et les performances du code utilisé à ce moment sont cruciales pour l'interactivité du jeu. C'est le même problème pour swing. L'utilisateur qui doit attendre une demi-seconde la première fois qu'il clique sur un menu parce qu'il faut byte-compiler la sur-couche swing d'une vague fenêtre motif va être assez ennervé, même si les fonctions complexes déclenchées par le GUI sont exécutées très rapidement.
il suffit de savoir lire
Oui, oui, en particulier We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation., mais ça, tu ne risques pas de le citer, n'est-ce pas...
Mais bon, tout ça, c'est trop compliqué, d'ailleurs "Java rulez dans l'embarqué" et "la mémoire a un coût dérisoire, quelle importance si ça en bouffe beaucoup" (sic) n'est-ce pas :-))
Tu ne sembles pas savoir que la J2ME a une occupation mémoire très faible (beaucoup plus faible que celle de la J2SE dont il est question dans ton mémo). L'adoption de Java sur les téléphones portables me semble assez symptomatique. J'ai comme l'impression que les fabriquants connaissent mieux le problème que toi. D'autre part, je maintiens que la mémoire ne coûte rien sur un PC et donc que les problèmes de la J2SE ne sont pas si graves que ça.
Enfin, bon, ton gros problème est que tu t'es engouffré bille en tête dans une discussion à laquelle tu n'as rien compris mais où il te semblait scandaleux qu'on critiquât Java, n'est-ce pas ? Ayant dû abdiquer le débat sur les jeux video où tu t'es fait ramasser par plusieurs personnes à cause de ton manque chronique de connaissances en la matière, tu es maintenant réduit à lancer des attaques personnelles et à ressasser quelques arguments déjà plusieurs fois réfutés ;)
Oui oui, bien sûr. C'est marrant, mais ayant développé (en C) la gestion du son et la version 2 du pathfinding de freecraft (pas la version 3, je l'avoue), j'avais l'impression d'avoir une vague idée de ce qu'est un jeu. Je pensais aussi que la lecture régulière de gamasutra m'aidait un peu dans cette compréhension. Mais apparamment non, j'ai un manque chronique de connaissances en la matière (j'aime bien les insultes polies, ça m'a toujours fait beaucoup rire. Je suis plus direct, en général, mais bon, je respecte l'art de l'insulte polie). D'autre part, tu devrais relire https://linuxfr.org/comments/221368.html(...) Peut être que tu ne comprends pas ma première phrase, mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.
Allez, va, c'est ma dernière réponse, je ne peux pas lutter contre un grand réfutateur d'argument qui connaît si bien le jeu vidéo.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à -1.
D'où vient cette manie de se restreindre à un domaine réduit quand on répond à une affirmation générale ? Ah oui, c'est vrai : tu comprends que ton argument est foireux, donc tu déplaces la discussion. Comme si personne n'avait rien vu ;)
A propos de fps, un autre intervenant a posté des chiffres factuels sur les performances d'un Quake en Java. Je suis sûr que tu auras à coeur de trouver de multiples excuses aux performances pour le moins faiblardes de cette version (largement inférieures à 50 fps). Et puis : si ton jeu tourne à 150 fps, ça te permet de descendre à 50 fps avec un jeu trois plus complexe (en affichage, en IA, en moteur physique...). Pas trop dur à comprendre.
Oui, oui, en particulier We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation
Sauf que les chiffres cités pour Solaris sont à peu près égaux à ceux cités ici par d'autres personnes en ce qui concerne Linux (et que tu n'as pas contestés).
D'autre part, je maintiens que la mémoire ne coûte rien sur un PC
Le mémo que je citais (oui, encore une fois) ne parlait pas que de HelloWorld. Il constatait aussi que l'occupation mémoire augmentait beaucoup plus avec la taille des données en Java qu'en Python. De plus l'occupation mémoire a des coûts en terme de performances (cache miss, etc.).
Surtout, tu confonds deux choses : le coût de la mémoire, et la volonté qu'ont les utilisateurs potentiels d'upgrader la mémoire de leur machine. Si une seule appli se met à ramer parce qu'elle a besoin de trop de mémoire, les gens ne vont pas ajouter une barrette (c'est de toute façon au-delà de leurs compétences pour la majorité), ils vont simplement trouver que l'appli n'est pas performante.
L'adoption de Java sur les téléphones portables me semble assez symptomatique. J'ai comme l'impression que les fabriquants connaissent mieux le problème que toi.
J'ai surtout l'impression que les applis présentes sur un téléphone portable, et les contraintes d'utilisation y afférentes (vu l'ergonomie désastreuse du bidule, pas besoin d'un temps de réaction < 100ms), font que les performances ne sont pas vraiment cruciales sur ce genre de produits. De plus, ces applis ne sont pas "coeur de métier", c'est juste un bonus pour attirer les gogos, la qualité n'est pas importante.
Mais apparamment non, j'ai un manque chronique de connaissances en la matière
Oh, pas du tout. Tu as juste raconté des bêtises sur 1) la soi-disant stagnation des performances des compilateurs C ; 2) le soi-disant peu d'importance des performances CPU dans les jeux modernes ; 3) le soi-disant fossé de performances de C et C++ par rapport à l'assembleur codé à la main ; 4) la soi-disant utilisation courante de Java dans les jeux actuels alors que le seul exemple que tu as trouvé ne concerne que l'utilisation en tant que langage de script.
Non, c'est vrai, si tu lis Gamasutra, c'est forcément que tu as raison ! Et si tu as codé des bouts de Freecraft en C, c'est bien la preuve que Java ownz les jeux video, hein ;)
Ah, et le meilleur pour la fin :
j'aime bien les insultes polies
Si tu penses que relever un manque de compétences est une insulte, tu dois être assez susceptible dans la vie quotidienne non ? (tu es libre d'y voir une insulte polie :-))
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à -1.
D'où vient cette manie de se restreindre à un domaine réduit quand on répond à une affirmation générale ? Ah oui, c'est vrai : tu comprends que ton argument est foireux, donc tu déplaces la discussion. Comme si personne n'avait rien vu ;)
Mais bien sûr. J'ai dit :
La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu
mais voir qu'on peut faire aussi bien en Java sans passer par une optimisation de très bas niveau, prouve effectivement que Java fonctionne correctement.
SDL est une super bibliothèque très optimisée qui est interfacée correctement avec Perl, d'où de bonnes performances. Mais on peut faire aussi jouable en Java sans assembleur, sans accès direct à la mémoire vidéo, etc. De même, OpenGL est super optimisé et remarquablement bien interfacée avec Java, ce qui permet de programmer objet tout en obtenant d'excellentes performances.
De très nombreux langages ont choisis de se baser sur gtk avec des performances excellentes. De même, les performances de swt en Java sont très bonnes. J'en déduis donc que le probème de swing n'est pas Java, mais swing. Si tu ne comprends pas, je n'y peux rien.
si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
De ce fait, avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage
etc., je ne vais pas recopier intégralement des posts que tu ne lis pas. Maintenant, cherche bien là dedans (et dans le reste) et dis moi à quel moment j'ai nié ton histoire d'importance relative du langage. C'est toi qui a écrit que je pensais le contraire.
Et puis : si ton jeu tourne à 150 fps, ça te permet de descendre à 50 fps avec un jeu trois plus complexe (en affichage, en IA, en moteur physique...). Pas trop dur à comprendre.
Oui, ou encore de descendre à 50 fps si le reste du jeu est implémenté dans un langage qui rame. Bravo, tu as compris ce que je me tue à t'expliquer depuis plusieurs posts (cf avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage).
la soi-disant stagnation des performances des compilateurs C
Ton super exemple est gcc (très utilisé pour compiler les jeux commerciaux), pour lequel je veux bien croire que les performances ont augmenté, heureusement, malgré ses nombreuses qualités gcc a toujours été très en retard sur les compilateurs commerciaux (par exemple sur alpha, c'était une catastrophe). J'aimerais savoir quelle a été la progression des compilateurs C commerciaux sur les 10 dernières années (pour le C++, la progression est énorme). Ton autre super argument est la prise compte d'un hardware moderne. Formidable. C'est aussi le cas dans tous les autres langages. De toute manière, je suis persuadé que les compilateurs C ont très peu progressé par rapport aux compilateurs C++ et à la JVM.
Ceci étant, pour te faire plaisir, je veux bien dire que j'ai dit une connerie.
le soi-disant peu d'importance des performances CPU dans les jeux modernes
J'ai dit De plus, le discours sur les performances me fait bien rire.. C'est bizarre mais j'ai l'impression que ce n'est pas exactement la même chose. Et je maintiens que Carmack a été très réticent pendant des années à passer au C++ pour des raisons de performances et de bugs des compilateurs. Or, aujourd'hui, plus personne ne critique le choix du C++ pour programmer l'essentiel d'un jeu. Mon argument était juste de dire que je pense que dans quelques années (disons j'espère), l'argument "Java ça rame" sera devenu aussi pertinent que celui "C++ ça rame".
le soi-disant fossé de performances de C et C++ par rapport à l'assembleur codé à la main
Alors la, bravo. Trouve moi la citation qu'on rigole. Et ensuite, va lire les articles sur ATLAS pour voir ce qu'on peut gagner en passant à l'assembleur (par rapport au C). Les programmeurs codent les jeux en C++ parce que la perte de performance est largement compensée par le hardware actuel et les économies en temps de développement, pas parce qu'ils sont sur que l'assembleur engendré est aussi bon que ce qu'ils pourraient faire à la main. Et je ne connais pas de bench significatif concernant la qualité du code engendré (les parties d'ATLAS concernées sont très spécifiques).
la soi-disant utilisation courante de Java dans les jeux actuels alors que le seul exemple que tu as trouvé ne concerne que l'utilisation en tant que langage de script.
Aller, trouve moi la citation qu'on rigole de nouveau.
Non, c'est vrai, si tu lis Gamasutra, c'est forcément que tu as raison !
Je suppose que tu travailles dans un grand studio de développement de jeux (et tu ne connais pas Vampire The masquerade ?). Parce que sinon, tu fais comment pour savoir ce qui est utilisé comme techno dans les logiciels propriétaires que sont les jeux ? Personnellement, je lis gamasutra. Mais c'est vrai que je suis incompétent.
Et si tu as codé des bouts de Freecraft en C, c'est bien la preuve que Java ownz les jeux video, hein ;)
Ba oui, c'est d'ailleurs exactement ce que j'ai dit (tu dois pouvoir trouver la citation quelque part). D'ailleurs, c'est sûrement pour rien que j'ai dit mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.
Tu peux toujours faire de l'ironie à deux centimes. J'ai juste voulu indiquer que j'avais quelques compétences en jeux vidéo, contrairement à ce que tu affirmes. Quelles sont les tiennes, à part une grande bouche ?
Si tu penses que relever un manque de compétences est une insulte, tu dois être assez susceptible dans la vie quotidienne non ? (tu es libre d'y voir une insulte polie :-))
D'après le grand robert, crétin signifie "personne sotte, stupide". Je te suggère donc de remplacer dans mes phrases "tu es un crétin" par "tes arguments sont stupides". C'est plus long et moins direct, et éventuellement un peu moins une généralisation hâtive (c'est vrai que tu utilises peut être des arguments intelligents dans d'autres contextes). Au final, tu obtiendras ce que j'appelles une insulte polie, mais ça ne semble pas te gêner, alors allons pour l'insulte polie.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à -1.
Qu'est-ce que ça vient faire ici ? On parle des performances actuelles de Java. Si tu es capable de prédire les performances de Java dans 5 ou 10 ans, tant mieux pour toi. Note que les problématiques de compilation de Java ne sont pas vraiment les mêmes qu'en C++ (sinon elles seraient déjà résolues), ce qui rend l'analogie peu convaincante.
Et je maintiens que Carmack a été très réticent pendant des années à passer au C++
Quelle est la pertinence de Carmack dans cette discussion ? Les scrupules de Carmack n'ont rien à voir avec un argumentaire d'ordre général, tu ne crois pas ? C'est comme ton magnifique argument sur les prétextes de MDI pour la création de Gnome (que le langage utilisé par KDE soit la raison déterminante de la création de Gnome, tout le monde y a cru, bien évidemment :-)).
Du reste, je ne vois pas pourquoi tu t'acharnes sur C++. Que les compilateurs C++ aient beaucoup progressé en quelques années, tout le monde le sait. Cependant ils étaient déjà largement exploitables il y a quatre ou cinq ans. Les fonctionnalités les plus importantes pour les jeux (templates peu complexes, inlining) fonctionnaient très bien.
De toute manière, je suis persuadé que les compilateurs C ont très peu progressé par rapport aux compilateurs C++ et à la JVM.
"Par rapport à", peut-être. Et alors ? Dans une discussion qui comparait l'utilisation de C et de l'assembleur dans les jeux video, tu te mets tout d'un coup à invoquer C++ et Java ?
Et ensuite, va lire les articles sur ATLAS pour voir ce qu'on peut gagner en passant à l'assembleur
Oh, merci de ne pas me faire dire ce que je n'ai pas dit. Je n'ai jamais dit que l'assembleur était toujours inutile, j'ai dit que dans la majorité des cas le code généré par un compilateur était aussi sinon plus performant, et cela expliquait que C/C++ était dominant dans les jeux depuis quelques années (tu ne contestes pas cette évidence, n'est-ce pas ?). Ce n'est pas le cas des calculs mathématiques et/ou vectorisables. (relis ce que j'ai dit sur le SSE, qui est utile pour optimiser les calculs 3D).
Personnellement, je lis gamasutra. Mais c'est vrai que je suis incompétent.
Quand comprendras-tu que tes lectures n'ont aucune incidence sur la crédibilité de tes arguments ?
mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu
Magnifique ! On est donc d'accord :) Je suis quand même curieux : pourquoi es-tu intervenu au tout début de la discussion, alors ? A cause du besoin impérieux de venir jouer les midinettes dans un thread qui mettait en doute les performances de Java ? Tu es émotif quand on parle de langages informatiques ?
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par yoplait . Évalué à 2.
y a pas que quand il parle de java... : http://linuxfr.org/2002/08/03/9162.html(...)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par dinomasque . Évalué à 5.
Par contre il faudra faire preuve d'une mauvaise foi sidérante pour affirmer qu'une interface graphique en Java offre un semblant d'utilisabilité tellement c'est poussif même sur les machines les plus véloces.
BeOS le faisait il y a 20 ans !
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Romain Guy . Évalué à 3.
Essaye, tu verras.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Roger Rabbit . Évalué à 3.
sous windows c'est nettement mieux
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par N/A . Évalué à 1.
Et c'est un FAIT.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Éric (site web personnel) . Évalué à 2.
La question est-ce : est ce que ca remet en cause le langage ?
Non parce que c'est aussi potentiellement le software qui est mal programmé ou le téléphone qui est un peu faiblard.
Perso je trouve aussi que mon téléphone (pas java du tout) réagit lentement, comme quoi ca n'a pas forcément à voir avec le langage. Je suis aussi capable de faire un truc qui rame en C ou assembleur.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Yusei (Mastodon) . Évalué à 3.
Alors j'veux bien, Java c'est rapide, mais j'attend toujours de voir. Et c'est pas faute d'essayer occasionnellement, contrairement à ce qu'on peut lire parfois.
Mais promis, je dirai à mon ordinateur qu'il se trompe, et qu'il ne devrait pas ramer autant ;-)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Benoît Bailleux (Mastodon) . Évalué à 2.
En fait Java n'est pas spécialement rapide. OK.
Mais ce n'est pas non plus spécialement lent, sauf quand on utilise certaines bibliothèques +/- bien concues ou implémentées. Point.
Les avantages sont ailleurs, à mon avis.
Ceci dit, au boulot j'utilise un PIII 450MHz avec Win2000, et Eclipse tourne étonnament bien. Moi je dit : bravo les développeurs et bravo Java.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Etienne Juliot (site web personnel) . Évalué à 2.
Ca avance à rien cette discussion.
Java n'est qu'un langage, et il est clairement bien fait (plus de pointeur, bien concu, bien documenté, ...).
Après, qu'il soit lent, ce vient de la JVM.
Bref, si vous trouvez Java trop lent, aidez le projet GNU en participant à Classpath (l'implémentation de la JFC (la bibliothèque Java) en GPL utilisée notamment par GCJ).
http://www.gnu.org/software/classpath/classpath.html(...)
Là au moins, on a le droit d'optimiser comme on peut/veut et il n'y a plus d'excuses valables.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Geo Vah . Évalué à 2.
Donc ca tourne quand même, et l'api 3D de java utilise openGL il me semble, donc en 3D ca tourne aussi.
Par contre je suis d'accord que la GUI est lourde et lente
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par tene . Évalué à 2.
Mes 2 cents ;)
Sinon je suis curieux de voir comment ils vont s'intégrer à OO.org...
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Geo Vah . Évalué à 1.
C aussi chiant qu'un makefile, mais aussi tôt que l'on maitrise quel bonheur :
Récupération du code source via cvs, compilation, installation,etc...
Vive Ant ! Vive Makefile !
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par superpop . Évalué à 1.
Franchement je trouve l'interface graphique ideuse ...
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Roger Rabbit . Évalué à 7.
en utilisant skinlf.jar de lf2prod, tu peux utiliser
1- les themes natifs skinlf
2- les themes kde
3- les themes gnome
un petit screenshot de mon netbeans utilisant le look "alloy"
de kde
http://antonin.tuxfamily.org/capture4.png(...)
skinlf fonctionne avec toutes les GUI swing, et on peut changer
le look d'un application en ligne de commande , si on ne veut/peux
pas changer le code d'un soft.
le theme swing sera complétement revu pour le jdk1.5 [ cf une
ancienne discussion ]
pour plus d'infos sur skinlf :
http://www.l2fprod.com/(...)
pour récuperer des skin swing [ skinlf ou L&F standards ]
http://www.javootoo.com/(...)
autres screenshots de swing thémé :
http://www.incors.com/lookandfeel/abeille.png(...)
http://www.incors.com/lookandfeel/jprofiler1.png(...)
pour rire :
http://javootoo.l2fprod.com/plaf/xp/screenshot_xp.jpg(...)
pour lancer netbeans avec des themes :
tu downloade http://www.l2fprod.com/download/files/latestskinlf.php(...)
tu le decompresse
tu copie le fichier skinlf.jar dans le repertoire /ext de netbeans
ensuite, il faut choisir le type de theme, 3 types :
1) theme skinlf
tu peux les downloader à http://www.javootoo.com/(...)
2) themes qt
3) themes gtk
ensuite utiliser les themes
1) theme skinlf :
/opt/netbeans/bin/runide -mainclass Skinit -pack \themes\aquathemepack.zip
org.netbeans.Main
2) theme kde
crée un ~/.skinlf
détarre la version de dev de skinlf et mets y themepack.zip
ensuite pour lancer :
/opt/netbeans/bin/runide mainclass Skinit -kde
/usr/kde/3.1/share/apps/kstyle/themes/alloy.themerc org.netbeans.Main
3) themes gtk :
runide -mainclass Skinit -gtk /usr/share/themes/Chrome/gtk/gtkrc
org.netbeans.Main
NB : tu peux configurer netbeans dans
/opt/netbeans-3.4.1/bin/ide.cfg
en mettant par exemple
-J-Xverify:none -J-Xms24m -J-Xmx96m -mainclass Skinit -kde
/usr/kde/3.1/share/apps/kstyle/themes/alloy.themerc org.netbeans.Main
Pour C/C , toutes les appz swing sont largement et facilement thémables,
apres on aime ou on aime pas .....
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par herve . Évalué à -1.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Romain Guy . Évalué à 2.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par tene . Évalué à 0.
D'accord, mais:
- il faut déployer java web start avant... et avoir l'infrastructure nécessaire pour le faire fonctionner.
- tu crois que ce sera utilisable pour le reste des applications OO.org?
- tu ne trouves pas que c'est encore un peu plus d'enfoncer dans les techno java?
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Le type de base Object prends déjà plusieurs octets, un Integer prends plus de 20 octets, ... Pour lancer le moindre pgme, il faut lancer une JVM, qui te bouffe déjà de l'ordre de 16Mo de RAM. (Ca, c'était la dernière fois que j'ai regardé. Ca a peut être bougé.)
Avec les compilo Just In Time, on a une execution assez rapide, mais le lancement est forcément plus lent ...
Bref, il y a des applications pour lesquelles les lacunes de Java en terme de performance ne sont pas un problème, mais ce n'est pas le cas partout.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à -2.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par huhuhu . Évalué à 3.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Thomas Cataldo (site web personnel) . Évalué à 2.
C'est la partie sur la consommation mémoire du bouquin de sun sur la performance des applications Java. Le livre présente aussi pas mal de technique pour limiter la consommation de mémoire, optimisez le temps de démarrage d'une application, etc. En gros il apporte des réponses aux personnes qui restent dans l'idée qu'une appli java ça met forcément longtemps à démarrer et ça bouffe plein de ram.
On trouve plein de petites choses intéressantes dans ce livre comme par exemple comment copier un fichier. Ils présentent 4 façons de le faire, de la façon neuneu à la façon correcte. Les temps d'executions des 4 méthodes sont (en ms) : 10800, 130, 33 et 22. Donc la méthode correcte/optimisée est 490 fois plus rapide que la méthode neuneu. Evidemment si on compare avec le même programme en C/C++, on va surement 2 ou 3 fois plus vite en C/C++. Le but de ce bouquin n'est pas de montrer que Java ça casse tout, c'est juste de montrer que la pluspart des arguments avancés contre Java ne sont pas forcément liés à la JVM et à son utilisation de la RAM.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Gabriel Santonja . Évalué à 1.
Bon je n'en ai pas trouve un qui ne rame pas mais j'ai pas teste emacs :))).
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Frédéric Lopez . Évalué à 3.
C'est une bonne idée de citer un jeu vidéo comme exemple, vu que c'est un domaine où le besoin en performance est élevé, mais là il faudrait trouver un peu mieux pour convaincre.
Le seul exemple de jeu commercial que je connaisse qui devait contenir du Java était Rainbow Six, mais ils ont abandonné à cause des difficultés d'intégration avec C++. Et Java ne devait concerner que la partie réseau...
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Je n'ai jamais dit que le jeu etait techniquement en avance ou qu'il etait terminé... lis ma phrase please...
J'ai juste dit que ce jeu qui est en 3d tourne bien... voila
http://about.me/straumat
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par jeanmarc . Évalué à 1.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par vrm (site web personnel) . Évalué à 2.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à 1.
Tu es mal comprenant ?
C'est une bonne idée de citer un jeu vidéo comme exemple, vu que c'est un domaine où le besoin en performance est élevé, mais là il faudrait trouver un peu mieux pour convaincre.
Tu connais des jeux open sources qui sont au niveau des jeux commerciaux ? Franchement ? De plus, le discours sur les performances me fait bien rire. Il y a quelques années, tout le monde disait qu'il fallait faire les jeux en assembleur. Ensuite on est passé au C et maitenant tous les moteurs sont en C++ (Doom III par exemple). Alors franchement...
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à -1.
"Quelques années" = 10 ans au moins. Le C et le C++ sont bien installés dans les studios de jeux depuis des années.
Ensuite on est passé au C et maitenant tous les moteurs sont en C++
La différence, c'est que la plupart du code généré en C ou C++ est meilleur que le code qu'aurait programmé un humain en assembleur. Cependant, je te rassure, il y a toujours des parties critiques codées en assembleur (notamment, les transformations 3D gagnent à utiliser le SSE... évidemment avec les vertex shaders ce sera bientôt dépassé).
Tu connais des jeux open sources qui sont au niveau des jeux commerciaux ?
On retourne donc la question : tu connais des jeux commerciaux qui sont programmés en Java ?
Allez, game over ;)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à 0.
Oui, et alors ? Les performances des compilateurs C ont augmenté ?
Le C et le C++ sont bien installés dans les studios de jeux depuis des années.
Pour le C, c'est vrai au moins depuis doom (qui n'avait presque pas d'assembleur). Pour le C++, c'est beaucoup moins vrai. Quake III est programmé en C.
La différence, c'est que la plupart du code généré en C ou C++ est meilleur que le code qu'aurait programmé un humain en assembleur.
C'est marrant, quand le projet gnome a débuté, l'argument principal était que le C++ c'est horrible, ça rame à mort, les compilateurs ne marchent pas et le code généré est vachement moins bien que ce qu'on peut faire avec du C. Et maintenant, plus personne ne dit ça. Amusant, non ?
On retourne donc la question : tu connais des jeux commerciaux qui sont programmés en Java ?
C'est quoi le rapport ? T'es idiot ou quoi ? L'argument sur la qualité d'un jeu évoqué par mon interlocuteur de départ n'a rien à voir avec Java mais avec le fait que les jeux open source sont ou bien moches ou bien avec des dessins très mignons (comme frozen bubble), mais très en retard sur les jeux actuels.
D'autre part, java a été utilisé depuis des années dans des jeux commerciaux, comme par exemple Vampire the masquerade qui a remplacé son langage de script proprio par du Java. De plus, Java est très utilisé en embarqué pour les jeux sur téléphone et certains PDA. L'un des premiers middleware pour les jeux de roles online est écrit en Java, etc. Mais en fait, tu t'en moques, n'est-ce pas ?
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Moby-Dik . Évalué à 1.
Rassure-moi : tu en doutes sérieusement ? Rien qu'entre gcc 2.9x et gcc 3.0, elles ont fait un bond très sensible, et mesuré. De plus le x86 est un processeur peu sympa pour les compilos (jeu d'instructions foisonnant et peu orthogonal, très peu de registres, règles d'optimisation variables d'un processeur à l'autre et parfois délirantes (pipelines U et V du Pentium...)), ce qui fait qu'il y a eu beaucoup de marge pour l'optimisation du code généré. Cf. pgcc (le gcc optimisé Pentium), egcs (forké de gcc à l'époque où celui-ci stagnait en performances)...
Quake III est programmé en C.
Quake 3, étant sorti il y a quatre ans a été commencé il y a encore plus longtemps, et comme il s'agit d'une suite il est probable qu'ils n'aient pas voulu tout remettre à plat. En tout cas à l'époque où Quake 3 était sorti, certains studios travaillaient déjà en C++, et les compilateurs produisaient déjà du code de bonne qualité (en tout cas celui de Visual Studio).
quand le projet gnome a débuté, l'argument principal était que le C++ [...]
Que viennent faire ici les prétextes peu crédibles du projet Gnome ? Tout le monde sait que Gnome a été créé 1) à cause de la licence de Qt à l'époque 2) parce que RMS et MDI voulaient leur propre desktop (syndrome Not Invented Here + ego surgonflé des deux Messieurs).
mais avec le fait que les jeux open source sont ou bien moches ou bien avec des dessins très mignons (comme frozen bubble), mais très en retard sur les jeux actuels
Oui. Et je te réponds que les "jeux actuels" ne sont pas écrits en Java. Conclusion : les jeux "à l'heure" sont en C/C++, les jeux "en retard" sont en Java. C'est difficile à avaler ?
java a été utilisé depuis des années dans des jeux commerciaux, comme par exemple Vampire the masquerade qui a remplacé son langage de script proprio par du Java
Super : Java est utilisé comme langage de script et non comme langage principal, ce qui disqualifie complètement l'exemple donné. En plus, Java comme langage de script... J'ose à peine imaginer les difficultés des scripteurs qui ont dû se mettre à Java alors que la programmation avancée n'est pas leur métier.
Et puis, finalement, que le seul exemple que tu trouves est un jeu relativement peu connu (alors que pour C et C++ tu cites Quake 3 et Doom 3 ;-)) ne fait que confirmer que Java n'est pas à proprement parler très adapté à la programmation de jeux. Il y a de mauvaises décisions partout, mais le fait que l'immense majorité des jeux "actuels" (par opposition aux jeux "en retard") soient actuellement codés en C ou C++ ne laisse guère de doute sur l'intérêt de Java dans le domaine, n'est-ce pas ?
De plus, Java est très utilisé en embarqué
Ah oui, quand on parle de jeux temps réel et d'interfaces graphiques sur un PC de bureau, le démineur en Java sur un téléphone portable est un argument très pertinent.
Surtout que de tes propres dires : http://linuxfr.org/comments/220801,1.html(...)
La RAM, en embarqué, trop facile d'en ajouter ;)
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à 0.
Déjà entendu parler de J2ME ? Non. Laisse tomber.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par vrm (site web personnel) . Évalué à 2.
http://www.puppygame.com(...)
sinon plein d'autre :
http://community.java.net/games/(...)
de plus Sun annonce au JavaOne la création d'une section Games
Il commence a developper des binding OpenGL & OpenAL et une partie serveur pour jeux réseau style MOG
perso je programme un bidule dans mon coin : openGL & Java => 200 FPS limité à 60, c'est vraiment pas plus lent que le faire en C++, juste la consomation mémoire est un peu problématique mais on s'y fait.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Frédéric Lopez . Évalué à 2.
Euh, non, mais rien ne t'empêche de donner des exemples de jeux commerciaux programmés en Java si tu en trouves. Pas pour la couche réseau ou le scripting hein, je parle de jeux vraiment écrits en Java.
Sinon comme exemple de moteur 3d libre proche de ce qui se fait de mieux à l'heure actuelle, il y a Tenebrae (http://tenebrae.sourceforge.net/(...) ) et il est codé en C. Des volontaires pour le porter en Java et montrer que ce serait aussi rapide et aussi peu gourmand ?
De plus, le discours sur les performances me fait bien rire. Il y a quelques années, tout le monde disait qu'il fallait faire les jeux en assembleur. Ensuite on est passé au C et maitenant tous les moteurs sont en C++ (Doom III par exemple). Alors franchement...
L'assembleur était rarement utilisé pour coder un jeu complet, les programmeurs savent depuis belle lurette qu'on n'optimise que les fonctions qu'on appele souvent. Je ne vois pas où tu as pu lire que "tout le monde disait qu'il fallait faire les jeux en assembleurs". Et en quoi le fait de passer du C au C++ implique une perte de performance ?
J'ai l'impression que tu veux dire que le langage est de moins en moins important pour la programmation de jeux puisque on utilise des langages de moins en moins rapide. Je ne suis pas d'accord avec ça. On utilise toujours l'assembleur, que ce soit au niveau CPU ou GPU. Et C et C++ sont encore considérés comme les langages les plus rapides du marché.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Frédéric Lopez . Évalué à 2.
Configurations minimales requises :
Version Java :
- 500 MHz Pentium® III or equivalent
- 256MB RAM
Version originale en C :
- A Pentium 90 or better (133 recommended) computer
- 16 MB RAM (24 recommended)
Les deux applications utilisent les mêmes données, celles de la version shareware de Quake (pak0.pak). Sur ma machine (K6/350,TNT2,132Mo), la version Java tourne à 5 fps et met plusieurs minutes à se charger, la version C tourne à 70 fps et se charge instantanément. Sur la même machine, Quake 3 tourne en moyenne à 30/40 FPS et la qualité du rendu est nettement supérieure à ces deux versions de Quake.
Il faudra sans doute attendre que les sources de l'appli Java soient disponibles (sous licence MIT/BDS probablement) pour vérifier que les deux versions font vraiment la même chose. En tout cas le projet semble intéressant, mais en dehors du cadre des jeux vidéo.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à 1.
En effet, c'est une catastrophe. Combien de ram utilise la version Java (un pauvre top devrait suffire) ? Quelle JVM et quelle option de démarrage ? Quel système ? Les différences sont étonnantes parce que l'implémentation est normalement basée sur un pont opengl (pas le même que arkanae) et pourtant, c'est vraiment tout pourri... Dernière remarque, les auteurs de la version Java disent que leur rendu est meilleur. Qu'en penses-tu ?
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Frédéric Lopez . Évalué à 2.
Résultats de "top"
Version Java :
- VIRT : 127m
- RES : 81m
Version C :
- VIRT : 61884
- RES : 26m
Quake 3:
- VIRT : 81132
- RES : 45m
A noter que l'occupation mémoire de la version Java continue à augmenter régulièrement après le lancement. On passe de 115m à 127m en moins d'une minute. Ca reste stable pour la version C et pour Quake 3.
Quelle JVM et quelle option de démarrage ?
La JVM est la 1.4.1_03 de Sun, c'est celle qui est fournie avec l'archive ri_preview_linux.tar.bz2 disponible sur le site du projet. Pour tester la version C, j'utilise le paquet quake-gl de la Debian/unstable, avec les options width 640, height 480, vid_glx_fullscreen 1 et show_fps 1 pour être dans les mêmes conditions.
Ligne de démarrage :
jre/bin/java -cp launcher.jar -Djava.ext.dirs=lib -Djava.library.path=lib/os/linux -ms150m -mx150m -XX:CompileThreshold=5 -Xincgc -XX:-PrintGCDetails com.realityinteractive.demo.launcher.Launcher
Quel système ?
Debian/unstable, kernel 2.4.20 compilé avec gcc 3.2 pour K6 avec un nombre limité de pilotes.
Les différences sont étonnantes parce que l'implémentation est normalement basée sur un pont opengl (pas le même que arkanae) et pourtant, c'est vraiment tout pourri...
Oui, c'est vraiment étonnant, comme quoi dans Quake, il semblerait qu'il n'y a pas que le rendu 3d qui compte. Sans oublier le fait que la version Java est une démo non jouable contrairement à la version C.
Dernière remarque, les auteurs de la version Java disent que leur rendu est meilleur. Qu'en penses-tu ?
Personnellement, je n'ai pas vu de différence visuelle entre les deux. Il y en a peut-être une, mais elle n'est pas assez évidente pour être remarquée au premier coup d'oeil. En tout cas, on voit une différence très nette avec Quake 3, qui tourne lui à 30/40 fps sur la même machine.
Si quelqu'un pouvait tester sur une autre machine, ça donnerait peut être un meilleur point de vue. Etant donné l'occupation mémoire de la version Java, mes 128 Mo de mémoire vive sont sans doute un peu justes. Et s'ils utilisent des extensions non disponibles sur ma TNT2, tester les deux versions sur une GeForce/Radeon permettrait d'être fixé.
Il n'en reste pas moins que la différence entre les deux versions est assez énorme. Un simple Pentium 90/16Mo suffit à faire tourner la version C alors qu'il faut un Pentium 500/256 Mo pour faire tourner la version Java. Je veux bien que les développeurs ne soient pas au niveau de ceux d'id Software, mais le code source de Quake est disponible depuis un bon bout de temps et ils ont eu tout le loisir de l'étudier et de l'améliorer. Sans oublier le fait qu'un jeu comme Cube développé indépendemment par un amateur (en C++) tourne très bien sur ma machine et offre un rendu plus proche de Quake 2.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (site web personnel) . Évalué à 0.
C'est sur qu'avec -ms150m -mx150m, ça ne risque pas de bien marcher sur ta machine (comme tu le dis toi même), puisque ça signifie que la JVM alloue 150 mo pour tourner. Je pense qu'une partie des mauvaises performances vient de ça. Je vais essayer de faire les tests sur ma machine (j'ai 256 mo), mais je n'ai pas un XFree récent (ni même décent), donc ça risque de merdouiller à la fois en C et en Java.
Je veux bien que les développeurs ne soient pas au niveau de ceux d'id Software
Tu es trop généreux avec Java. Je pense qu'ils ont du étudier le source pour ne pas faire trop d'erreur et que l'essentiel du problème vient de Java, essentiellement pour des raisons de mémoire. Mais cela n'est qu'une hypothèse. Comme il s'agit d'une démonstration technologique, elle me semble cependant plausible, au sens où les programmeurs ont quand même du faire pas mal d'effort pour obtenir quelque chose de potable.
Dernière remarque, il est probable que cela marche beaucoup mieux sous windows, c'est malheureux à dire, mais les JVM fonctionnent en général mieux sous l'os de ms...
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par ndesmoul . Évalué à 1.
Les performances peuvent dépendre également énormément de la JVM utilisée. En générale celle d'IBM (1.4.0) est plutôt plus performante que celle de SUN (C'est pas systématique mais j'ai déjà observé un facteur supérieur à 2 dans certains cas).
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par ndesmoul . Évalué à 1.
Chez moi ça tourne très bien.
Sur un PC AMD 700 Duron, 640 Mo de RAM, carte nVidia GeForce 2, Windows XP, j'ai 40 de fps.
Le programme met environ 25 s à se lancer.
Sur un Pentium 2,6 GHz, 256 Mo de RAM, carte ATI Radeon 9500 Pro, Windows XP: 60 fps. Le programme met environ 10-15 s à se lancer.
Dans les 2 cas la démo est lancée en: 1024x768x32 en pleine écran et avec le son.
J'ai pas regardé l'occupation mémoire et je n'ai pu faire ces essais que sous Windows, désolé.
J'ai pas réussi à lancer le Quake original depuis Windows XP (même en mode compatibilité) donc je peux pas comparer les perf. Les perf sont peut-être bien meilleures avec la version originale (en fait j'en sais rien); ceci dit cela montre que l'on peut tout de même faire des choses intéressantes question jeux en Java.
Cette démo nécessite apparemment un JRE 1.4.x. J'ai pas pu comparer avec la version d'IBM car sous windows ils en sont encore à 1.3.1: il faudrait tester sous Linux.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou (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.