La raison de ne plus utiliser les primitives de X, c'est qu'on veut des coins arrondis, de la transparence, et accessoirement utiliser le GPU pour ça (ce dernier point étant quand même pertinent).
Tout ça, ça implique d'utiliser OpenGL, et donc balancer des buffers pré-calculés au serveur graphique qui se contente de filer les pointeurs au GPU plutôt que de copier N fois ces fameux buffers résulte en simplification du code et amélioration des performances.
En fait, si on pouvait faire un toolkit qui utiliserait l'accélération 2D de Xorg, on pourrait avoir un truc réellement rapide sur le réseau, par contre, qui serait prêt, à l'heure actuelle, à se passer de toutes ces petites icônes, images & co hyper dures à compresser et gourmandes en BP? Qui serait prêt à se passer, en fait, de l'esthétique? (perso, ça me poserait aucun souci vu que je le fais déjà, mais je pense que je fais partie d'une minorité)
En gros, le pourquoi, c'est parce qu'on veut des trucs jolis, adaptés au rendu moderne, alors que X à été conçu à une époque ou l'efficacité primait sur le bling-bling (pour des raisons techniques, notamment).
Maintenant, je viens de me souvenir que, au moins OpenGL 1 (obsolète, je le rappelle) utilise une sorte de pile pour générer l'image. Je ne sais pas (mais alors vraiment pas, je m'y suis intéressé et ai abandonné quand il à été question de tesselation, d'autant que je me suis aperçu un peu trop tard qu'OpenGL 1 était... obsolète, snif, et que je n'ai rien trouvé de clair pour commencer à utiliser ces p***** de shader) s'il serait possible d'imaginer une transparence réseau ou l'appli envoie ce stack sur le réseau, et le PC client le reconstruit... peut-être que ça prendrai moins de BP?
[^] # Re: Autre problème, autre solution?
Posté par freem . En réponse au journal Disruptive innovation comme y disent aux states. Évalué à 4.
Mais on sait pourquoi.
La raison de ne plus utiliser les primitives de X, c'est qu'on veut des coins arrondis, de la transparence, et accessoirement utiliser le GPU pour ça (ce dernier point étant quand même pertinent).
Tout ça, ça implique d'utiliser OpenGL, et donc balancer des buffers pré-calculés au serveur graphique qui se contente de filer les pointeurs au GPU plutôt que de copier N fois ces fameux buffers résulte en simplification du code et amélioration des performances.
En fait, si on pouvait faire un toolkit qui utiliserait l'accélération 2D de Xorg, on pourrait avoir un truc réellement rapide sur le réseau, par contre, qui serait prêt, à l'heure actuelle, à se passer de toutes ces petites icônes, images & co hyper dures à compresser et gourmandes en BP? Qui serait prêt à se passer, en fait, de l'esthétique? (perso, ça me poserait aucun souci vu que je le fais déjà, mais je pense que je fais partie d'une minorité)
En gros, le pourquoi, c'est parce qu'on veut des trucs jolis, adaptés au rendu moderne, alors que X à été conçu à une époque ou l'efficacité primait sur le bling-bling (pour des raisons techniques, notamment).
Maintenant, je viens de me souvenir que, au moins OpenGL 1 (obsolète, je le rappelle) utilise une sorte de pile pour générer l'image. Je ne sais pas (mais alors vraiment pas, je m'y suis intéressé et ai abandonné quand il à été question de tesselation, d'autant que je me suis aperçu un peu trop tard qu'OpenGL 1 était... obsolète, snif, et que je n'ai rien trouvé de clair pour commencer à utiliser ces p***** de shader) s'il serait possible d'imaginer une transparence réseau ou l'appli envoie ce stack sur le réseau, et le PC client le reconstruit... peut-être que ça prendrai moins de BP?