Salut nal,
je ne sais pas si cela aurait mieux valu un post dans le forum ou pas de post du tout, mais bon voilà: j'ai écris plusieurs message sur W2 (Wayland&Weston) où j'indiquais que l'architecture (décoration gérée par le client) ne me semblait pas fameuse car déplacer/redimensionner des fenêtres pouvait être saccadé si l'application est lente à répondre, or c'est faux pour le déplacement des fenêtres avec Weston!
En fait, les décorations sont bien gérées par le client, mais une fois que le client détecte qu'on a cliqué sur la barre des titres, il dit à Weston de mettre l'application en "mode de déplacement" et c'est le serveur Weston qui va ensuite déplacer la fenêtre de manière autonome quand l'utilisateur bouge la souris jusqu'à ce que l'utilisateur relâche la souris.
Donc pas de communication serveur <--> client durant le déplacement d'une fenêtre, ça devrait être très fluide (même en distant) !
Le redimensionnement d'une fenêtre peut, lui, être saccadé si l'application est lente à répondre, mais notons que ça ne concerne que Weston pas Wayland, les dev de KDE prévoient par exemple d'utiliser une gestion des décorations côté serveur pas côté client.
Désolé si j'ai pu induire quelqu'un en erreur, mon excuse est que Weston est très peu documenté.
# Papa dat vos mortem, filium meum, et dimitte
Posté par coïn . Évalué à 10.
Tu es pardonné.
Pars en paix.
# Le client entre quand même en jeu
Posté par moi1392 . Évalué à 4.
De ce que tu dis là, en effet ça evite qu'une appli lente à répondre fasse saccader le mouvement de la fenêtre, mais elle doit quand même effectuer le changement d'état (passe en mode déplacement)
Donc si elle ne réagi pas au click de souris, pas de déplacement. Et si elle ne réagi pas au lacher de souris ? Déplacement perpétuel ou c'est wayland/weston/walibi qui détecte ça ?
[^] # Re: Le client entre quand même en jeu
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Et de même pour les boutons minimiser / fermer. Si l'appli est prise dans une boucle infinie, la fermeture n'aura jamais lieu.
[^] # Re: Le client entre quand même en jeu
Posté par gnumdk (site web personnel) . Évalué à 2.
Pour la maximisation, c'est effectivement ce qu'il se passe sous Windows.
Par contre, pour la fermeture, c'est totalement faisable avec les décorations coté client la preuve Windows le fait ;)
[^] # Re: Le client entre quand même en jeu
Posté par reno . Évalué à 4.
Weston ping continuement l'application donc si l'application ne répond pas il prend la main (à la Windows).
Mon problème était plutôt que se passe t'il si l'application est lente a réagir (mais pas suffisamment pour que Weston prenne la main), avec Weston ça veut dire que le redimensionnement d'une fenêtre sera saccadé, avec la décoration coté serveur le bord de la fenêtre se déplace de manière fluide mais le contenu peut être "moche" (tronqué ou avec l'ajout de bande).
[^] # Re: Le client entre quand même en jeu
Posté par reno . Évalué à 3. Dernière modification le 05 octobre 2012 à 16:09.
Yes, mais Weston pingue continuellement l'application et prend la main si l'application ne répond pas (à la Windows), donc ce n'est pas un vrai problème.
D'après ce que j'ai cru comprendre en lisant les sources, c'est Weston qui détecte le lacher de souris: pas besoin de l'application ici.
[^] # Re: Le client entre quand même en jeu
Posté par BFG . Évalué à 3.
La logique est donc placée dans le serveur d'affichage ? Il n'est pas possible d'imaginer utiliser le clavier pour déplacer la fenêtre ?
[^] # Re: Le client entre quand même en jeu
Posté par reno . Évalué à 3.
Le serveur d'affichage fait aussi gestionnaire de fenêtre si c'est ça la question, mais les décorations sont gérées par le client (Weston ne sait pas ou sont les menus).
Ce que j'ai décris correspond a "cliquer sur la barre de menu pour déplacer une fenêtre puis déplacer la souris en maintenant le bouton appuyé", mais ça ne veut pas dire qu'il n'est pas possible d'avoir d'autre façons de déplacer une fenêtre..
J'ignore ce que Weston a implémenté de ce coté là, au départ c'était censé être juste un serveur pour servir de modèle/prototype, mais je ne pense pas que ça en reste là.
[^] # Moi je trouve ça parfait
Posté par Enj0lras . Évalué à 1.
ça permet aux développeurs et aux utilisateurs de se rendre compte que l'appli est lente, et de se confronter à la réalité. Une fois fait, les devs et les utilisateurs peuvent travailler de concert pour régler ce problème.
Un seul exemple : Firefox.
En gros, ça exige de la qualité.
[^] # Re: Moi je trouve ça parfait
Posté par reno . Évalué à 4.
Tu oublie le cas ou le client est distant, dans ce cas là c'est un gain de gerer la deco coté serveur.
Mais tu as raison, le design de Wayland va bien avec des applications a la BeOS: une thread dédiée à l'IHM.
# moi aussi
Posté par cedric . Évalué à 3.
Les décorations coté client, j'ai toujours du mal a me faire a cette idée. Mais il faut dire qu'elle apporte un gain de performance non négligeable dans pas mal de cas. Le compositeur pouvant directement donner la surface du client ala carte graphique au lieu de le 'compositer' avec le gpu. En gros ça peu permettre sur mes benchmark un gain de 30% (ou 30% d'économie d'énergie ). C'est juste un exemple, il y a pas mal d'autres cas ou ça aide: rotation, fenêtre non rectangulaire,…
[^] # Re: moi aussi
Posté par reno . Évalué à 2.
Le dessin des décorations que le serveur n'a pas a faire, c'est le client qui le fait, donc en final ça doit revenir au même non?
[^] # Re: moi aussi
Posté par cedric . Évalué à 2.
Nop, car tu n'as pas dans certain cas besoin de repasser par le compositeur. Le client fait tout le rendu, ça évite une grosse copie dans le compositeur plus un rendu complet du reste de l'écran.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.