Travail/contribution upstream des patchs pour Qt, Gtk, ... avec détection au runtime, afin qu'un soft Qt/Gtk/EFL déjà compilé puisse tourner sous Wayland ou Mir.
GTK et Qt sont calculés pour supporter plusieurs backend sans avoir à recompiler les programme. A priori, on aura pas à recompiler les programmes pour faire tourner sous Wayland, X11 ou même Mir.
Je ne vais parler que pour les EFL, car c'est ce que je connais. Les porter sur un nouveau backend, se fait tres rapidement. En une semaine, tu as un truc qui pousse des pixels a l'ecran (Le port initial de Wayland a literalement pris 2 jours pour avoir une fenetre qui s'affiche a l'ecran avec le bon contenu).
Mais et c'est la que commence les joyeusetes, si tu veux un port efficace, tu dois rajouter de plus en plus de chose. Support du double et triple buffer, mise a jour partiel de l'ecran, support des sub-surface, minimisation des discussion entre le client et le serveur, suivit des changements upstream, ... Et ca, c'est de la maintenance qui occupe une personne presque a plein temps depuis un an ou deux (Pour X, meme apres 10 ans, le backend EFL recoit toujours des ameliorations). Ca, ca a un cout. Et il faut soit des personnes motives, soit qu'une societe paye une personne pour le faire.
Une strategie de fire and forget permet d'avoir une demo rapidement qui marche, mais ne permet pas du tout d'avoir une solution competitive. Cela veut dire que les toolkits utilisaient sur une tel plateforme seront plus lent, plus lourd et plus consommateur d'energie que si ils etaient utilise dans un environnement ou l'upstream fait la maintenance.
[^] # Re: Waylands et Mir ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 10.
Je ne vais parler que pour les EFL, car c'est ce que je connais. Les porter sur un nouveau backend, se fait tres rapidement. En une semaine, tu as un truc qui pousse des pixels a l'ecran (Le port initial de Wayland a literalement pris 2 jours pour avoir une fenetre qui s'affiche a l'ecran avec le bon contenu).
Mais et c'est la que commence les joyeusetes, si tu veux un port efficace, tu dois rajouter de plus en plus de chose. Support du double et triple buffer, mise a jour partiel de l'ecran, support des sub-surface, minimisation des discussion entre le client et le serveur, suivit des changements upstream, ... Et ca, c'est de la maintenance qui occupe une personne presque a plein temps depuis un an ou deux (Pour X, meme apres 10 ans, le backend EFL recoit toujours des ameliorations). Ca, ca a un cout. Et il faut soit des personnes motives, soit qu'une societe paye une personne pour le faire.
Une strategie de fire and forget permet d'avoir une demo rapidement qui marche, mais ne permet pas du tout d'avoir une solution competitive. Cela veut dire que les toolkits utilisaient sur une tel plateforme seront plus lent, plus lourd et plus consommateur d'energie que si ils etaient utilise dans un environnement ou l'upstream fait la maintenance.