eric b a écrit :
Bonjour,


N'ayant pas reçu le mail de la réponse de "Mitch" (caprice de la liste ...), je réponds directement ici.


[...]

Bien noter que tout ce qui précède relève du système d'exploitation utilisé, et de ce qui est installé, mais ne dépend pas d'OpenOffice.org
Bah, oui. Ouh, j'étais pas clair? Pardon.

Activer ou désactiver l'OpenGL dans OOo avec la case à cocher dans les préfs ne sert pratiquement à rien, et cela n'aidera absolument pas sous Windows (IMHO). En effet, cette implémentation d'OpenGL très ancienne est en dur dans vcl (que je connais très bien), et ne servait que pour l'affichage de certaines frames. J'ai eu la confirmation que cette implémentation était obsolète par Stephan Shaefer quand j'ai proposé de la reprendre pour la version Aqua (Mac OS X).

Après plusieurs recherches dans le code, la seule partie qui tire logiquement partie d'OpenGL dans OpenOffice.org, c'est la partie dynamique de Draw, aka Impress, est dont le code est contenu dans le module slideshow. (merci de me dire si vous avez d'autres infos)

Historiquement, c'est au cours d'un Google Summer of Code, que cela a été implémenté, mais pour Linux seulement ( cf http://wiki.services.openoffice.org/wiki/Impress:_OpenGL_rendered_transitions )

J'ai récemment fait la même chose sous Mac OS X, mais je n'ai curieusement jamais eu de retour des utilisateurs ??? ( les versions expérimentales sont ici : http://oooaqua.laurentbuisson.fr/ ) Plus d'infos sur comment j'ai fait (techniques, et en anglais ) ici : http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_OpenGL_transitions

D'ailleurs, comme je n'ai aucun retour, on ne pourra probablement pas intégrer ces transitions dans la 3.1 (version Mac OS X )...


Au passage, j'ai séparé les trois implémentations : Windows, Linux et Mac OS X, et si un jour mon code est intégré (il fonctionne parfaitement depuis plusieurs mois), les implémentations deviendront indépendantes.

En résumé :

L'openGL marche et n'est utile avec OOo que dans Impress, seulement pour les transitions 3D (une grosse dizaine), sous Linux (à condition d'installer l'extension), et sous Mac OS X avec mes versions expérimentales, ou si vous utilisez le cws ogltrans4mac dans votre propre build.

L'état actuel pour Windows : ne marche pas encore, développement en cours. Le dév qui s'en occupe est Maximilian Odendahl, alias mod.

La 3D qu'on voit partout ailleurs, utilise un rendu software.
Merci pour ces précisions, par contre arrête-moi si je me trompe, si l'accélération OpenGL est activée, alors les librairies systèmes (genre libGL) sont ouvertes par OO.o? Si ces librairies sont initialisées au lancement, même si elles ne sont pas utilisées, le fait qu'elles soit buggées peut générer les délais.

En gros, que l'implémentation d'OpenGL dans OO.o sente le renfermé ou pas n'a pas d'importance dans le bug présent, puisque le bug peut se manifester uniquement lors de l'appel de librairies OpenGL buggées.

Si par contre les librairies ne sont appelées que lors de leur utilisation, alors le bug est bizarre et pas lié à l'OpenGL...

(on va s'arrêter là, je n'oserais m'affubler de l'étiquette "développeur" et on tape dans un sujet plus approprié pour la liste 'devel', là).


Je me rappelle avoir vu passer des commentaires de développeurs OO.o à ce sujet il y a un moment...



En fait, il s'avère que le fonctionnement des transitions Impress a été sérieusement ralenti (sic) pour s'adapter au presenter screen, et je pense que le problème vient de là. Peut-être aussi un problème dans vcl (tout ce qui dessine des fenêtres et des rectangles). Un gros travail est en cours dans le but d'améliorer Impress, donc à suivre.

Pour conclure sur le sujet, je suggère de créer une issue pour ce qui se passe sous Windows, mais pour le reste, un peu de patience et ça ira :-)
si le problème n'arrive que sous Windows, c'est dommage de bloquer toutes les plateformes... surtout que le bug pourrait ne pas être propre à OO.o.


Voilà pour l'avis d'un développeur,
Eric Bachard



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Répondre à