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é.
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 boubou . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. É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.