J'ai vu un pote qui fait des jeux vidéos sur android.
La première chose qu'il fait, c'est "calmer" le framework java/dalvik à coup de JNI, pour passer en full natif opengl (NDK), langage C.
Personnellement, je pense que ça aurait été bien plus propre de proposer un framework en C avec des bindings officiels pour d'autres langages. Beaucoup plus de codeurs auraient été contents.
Y aussi mutter http://git.gnome.org/browse/mutter/ , le nouveau compositing window manager de gnome. Il irait de concert avec le toolkit clutter http://www.clutter-project.org/ ... tiens, je croyais que ct Qt le toolkit pour MeeGo? Sur la page www de clutter, ils disent que c'est eux.
Mon avis avec ce que ça vaut:
Le "use case" d'avoir un gestionnaire de fenêtres qui se configure au runtime ne m'est pas utile.
J'aurais préféré un modèle à la DWM. Cela économise le code/complexité d'un parser de configuration. Cela permettrait d'économiser un parser d'XML dans le cas d'openbox.
Bien entendu, ce n'est pas pour les utilisateurs lambdas.
Openbox est à mi-chemin.
J'ai beaucoup d'attirance pour awesome... mais cmake est interdit sur ma machine car C++. De plus je crois que LUA est obligatoire et n'est pas une option de compilation (à vérifier). Oui, si LUA n'est pas obligatoire, je pourrais faire un mini-build système pour GNU/Linux à base de makefile.
Cela à titre informatif: j'utilise openbox complètement customisé. J'ai un LXpanel en bas et un conky à gauche.
Pas de bordures de fenêtre, les raccourcis claviers qui me vont bien. Je fais les déplacements et tailles de fenêtres par des combinaisons souris/clavier (ALT+boutons en général).
Je suis souvent en plein écran aussi: Il faut bien déclarer les types de fenêtre (dock/desktop etc...) pour qu'openbox fasse au mieux son boulot pour minimiser l'utilisation de la souris.
Je n'ai pas encore expérimenté une extension de chromium pour une navigation maximisée au clavier (cf vimperator pour firefox).
mais alors que vient faire là le 3D de gallium3D? Un abus de langage? Si Gallium est générique et n'a pas de sémantique liée à la 3D, que vient faire le "3D" la dedans?
Bon j'avoue que je suis pas encore rentré dans le détails de Gallium/Gallium3D/DRI2.
Bon je mettais en avant le GPGPU, mais ça peut très bien être une API avec une sémantique pour faire les effets de physiques, ou du décodage vidéo tout simplement.
J'ai pas encore regardé dans le détail, mais j'ai l'impression que la futur interface Gallium3D risque d'être l'unique API d'accès au GPU. Or une interface "pas 3D" pour du GPGPU est très certainement à envisager.
Donc la question est simple... dans la nouvelle infrastructure des drivers de GPU, est-ce qu'il est prévu de pouvoir enregistrer une autre API que Gallium3D? Ça voudrait dire qu'il faudrait une API en dessous de Gallium3D qui permette l'utilisation d'une autre API (exemple une dont la sémantique est adaptée à du GPGPU) en parallèle de Gallium3D. Est-ce le DRI2?
Personnellement, je "vois" une API native à une architecture de GPU sur lequel en enregistre des APIs avec des sémantiques spécifiques à des traitements:Gallium3D pour la 3D et/ou "GalliumGP" pour du GPGPU.
[^] # Re: warning....
Posté par Sylvain Bertrand (site web personnel) . En réponse au journal Une nouvelle version des pilotes pour carte ATI/AMD vient de sortir.. Évalué à 0.
http://www.phoronix.com/scan.php?page=news_item&px=OTE2NA
[^] # Re: Ouééé
Posté par Sylvain Bertrand (site web personnel) . En réponse au journal Une nouvelle version des pilotes pour carte ATI/AMD vient de sortir.. Évalué à 2.
D'ailleurs, les modes vidéo seraient entièrement gérés par l'atombios.
Et cela dans le driver radeon.
# warning....
Posté par Sylvain Bertrand (site web personnel) . En réponse au journal Une nouvelle version des pilotes pour carte ATI/AMD vient de sortir.. Évalué à 6.
[^] # Re: dalvik?
Posté par Sylvain Bertrand (site web personnel) . En réponse au journal Symbian, Moblin/Meego et Android sont dans bateau nommé Nokia. Évalué à 0.
# dalvik?
Posté par Sylvain Bertrand (site web personnel) . En réponse au journal Symbian, Moblin/Meego et Android sont dans bateau nommé Nokia. Évalué à 3.
La première chose qu'il fait, c'est "calmer" le framework java/dalvik à coup de JNI, pour passer en full natif opengl (NDK), langage C.
Personnellement, je pense que ça aurait été bien plus propre de proposer un framework en C avec des bindings officiels pour d'autres langages. Beaucoup plus de codeurs auraient été contents.
[^] # Re: customisation openbox/lxpanel/conky
Posté par Sylvain Bertrand (site web personnel) . En réponse au message WM sans bureau et sans barre de tâche. Évalué à 1.
[^] # Re: customisation openbox/lxpanel/conky
Posté par Sylvain Bertrand (site web personnel) . En réponse au message WM sans bureau et sans barre de tâche. Évalué à 0.
# mutter
Posté par Sylvain Bertrand (site web personnel) . En réponse au message WM sans bureau et sans barre de tâche. Évalué à 1.
[^] # Re: customisation openbox/lxpanel/conky
Posté par Sylvain Bertrand (site web personnel) . En réponse au message WM sans bureau et sans barre de tâche. Évalué à 0.
Le "use case" d'avoir un gestionnaire de fenêtres qui se configure au runtime ne m'est pas utile.
J'aurais préféré un modèle à la DWM. Cela économise le code/complexité d'un parser de configuration. Cela permettrait d'économiser un parser d'XML dans le cas d'openbox.
Bien entendu, ce n'est pas pour les utilisateurs lambdas.
Openbox est à mi-chemin.
J'ai beaucoup d'attirance pour awesome... mais cmake est interdit sur ma machine car C++. De plus je crois que LUA est obligatoire et n'est pas une option de compilation (à vérifier). Oui, si LUA n'est pas obligatoire, je pourrais faire un mini-build système pour GNU/Linux à base de makefile.
# citadel
Posté par Sylvain Bertrand (site web personnel) . En réponse au message Cherche serveur IMAP + SMTP. Évalué à 1.
Entièrement codé en C, et du GNU GPLv3.
Perso, si je dois bosser sur un groupware, j'améliorerais celui-là en premier.
# customisation openbox/lxpanel/conky
Posté par Sylvain Bertrand (site web personnel) . En réponse au message WM sans bureau et sans barre de tâche. Évalué à 2.
Pas de bordures de fenêtre, les raccourcis claviers qui me vont bien. Je fais les déplacements et tailles de fenêtres par des combinaisons souris/clavier (ALT+boutons en général).
Je suis souvent en plein écran aussi: Il faut bien déclarer les types de fenêtre (dock/desktop etc...) pour qu'openbox fasse au mieux son boulot pour minimiser l'utilisation de la souris.
Je n'ai pas encore expérimenté une extension de chromium pour une navigation maximisée au clavier (cf vimperator pour firefox).
[^] # Re: API GPGPU
Posté par Sylvain Bertrand (site web personnel) . En réponse à la dépêche Lancement d'une implémentation native de Direct3D sous Linux. Évalué à 2.
Bon j'avoue que je suis pas encore rentré dans le détails de Gallium/Gallium3D/DRI2.
Bon je mettais en avant le GPGPU, mais ça peut très bien être une API avec une sémantique pour faire les effets de physiques, ou du décodage vidéo tout simplement.
# API GPGPU
Posté par Sylvain Bertrand (site web personnel) . En réponse à la dépêche Lancement d'une implémentation native de Direct3D sous Linux. Évalué à 2.
Donc la question est simple... dans la nouvelle infrastructure des drivers de GPU, est-ce qu'il est prévu de pouvoir enregistrer une autre API que Gallium3D? Ça voudrait dire qu'il faudrait une API en dessous de Gallium3D qui permette l'utilisation d'une autre API (exemple une dont la sémantique est adaptée à du GPGPU) en parallèle de Gallium3D. Est-ce le DRI2?
Personnellement, je "vois" une API native à une architecture de GPU sur lequel en enregistre des APIs avec des sémantiques spécifiques à des traitements:Gallium3D pour la 3D et/ou "GalliumGP" pour du GPGPU.
[^] # Re: Kyoto Cabinet
Posté par Sylvain Bertrand (site web personnel) . En réponse à la dépêche NoSQL : Neo4J, Riak, Kyoto Cabinet et Graylog2. Évalué à 0.
Kyoto cabinet est en C++. Tokyo cabinet est en C.
# synchronisation contacts et agenda
Posté par Sylvain Bertrand (site web personnel) . En réponse au message Le serveur domestique parfait. Évalué à 2.
Je me doute qu'il y en a un bon paquet... mais gnu/linuxiens que conseillerez-vous pour un serveur domestique?