Vous appuyez sur envoyer, puis vous passez au navigateur pour vérifier un point. La fenêtre Hermes reste en arrière-plan, streamant sa réponse caractère par caractère. Vingt minutes plus tard, vous refermez le capot, débranchez et partez. Au retour, la batterie a baissé plus que de raison, et le ventilateur était manifestement occupé pendant votre absence.

Une fenêtre cachée ne devrait pas fonctionner comme ça. Personne ne la regarde, et pourtant elle repeignait chaque caractère à la vitesse du premier plan.

L’ancien comportement : une conversation streame, toutes les fenêtres s’éveillent

Dans l’implémentation précédente, l’état « une conversation streame » maintenait toutes les fenêtres du bureau pleinement éveillées : la boucle de peinture continuait de tourner, et les pages d’aperçu étaient maintenues éveillées elles aussi, pour que la capture d’automatisation et d’annotation soit toujours prête.

Avec une seule fenêtre, c’était invisible. Avec plusieurs fenêtres, des tours longs et une batterie de portable, c’était un coût de fond permanent.

La moitié « aperçu » était plus subtile : même une page totalement inactive n’entrait jamais dans le throttling d’arrière-plan de Chromium, parce que l’annotation ou l’automatisation pourrait en avoir besoin à tout instant.

Maintenant : la peinture suit la visibilité

La peinture du stream est limitée à deux fenêtres : les fenêtres visibles, et la seule fenêtre qui a sa propre conversation vocale en cours (celle-là reste éveillée même cachée, parce que la voix en a besoin). Tout le reste — y compris les pairs réduits — est autorisé à throttler.

Notez bien ce que cela n’est pas : « Read replies aloud » n’offre plus à chaque fenêtre une exemption de veille. Auparavant, cela impliquait que chaque fenêtre devait rester éveillée pour énoncer son contenu ; désormais les pairs réduits restent throttlés et la progression achevée plus la réponse finale sont toujours énoncées exactement une fois.

En parallèle, ce qui ne doit pas dépendre du dessin a été découplé des images d’animation : livraison du stream, Stop, journal de tour et récupération après plantage fonctionnent sans elles. Restaurer une fenêtre montre le dernier état au lieu de rejouer un arriéré de peintures.

Les mises à jour de texte partiel sont fusionnées. La progression achevée et les réponses finales sont publiées sans attendre l’image suivante — c’est pourquoi une fenêtre cachée peut encore lire à voix haute, une fois. Quand deux fenêtres ont des réponses en même temps, elles partagent la propriété du tour en attente, si bien que la narration n’est ni perdue ni prononcée deux fois.

Pages d’aperçu : inactif veut dire inactif

Le second changement concerne l’aperçu intégré : une page inactive peut désormais utiliser le throttling d’arrière-plan de Chromium au lieu de retenir une veille pour elle-même.

La page invitée et la fenêtre qui la possède ne sont réveillées que pour du vrai travail, et la veille est retenue par opération. Les opérations qui se chevauchent gardent chacune leur propre retenue, donc en finir une ne peut pas suspendre une autre. Après une navigation, la veille est réappliquée même si une opération existante n’a pas encore envoyé d’autre script.

Plusieurs angles coupants ont été fermés en même temps :

• Le travail abandonné par une navigation validée est annulé, tandis que les valeurs de retour de script, le consentement des plugins, l’entrée de confiance, le sandboxing et la CSP restent intacts.
• L’attente de peinture d’annotation et la capture d’image partagent une même échéance annulable de huit secondes. Attendre la prochaine annotation de l’utilisateur ne maintient rien éveillé.
• Les installations et démontages d’annotation en file sont bornés par session, pour qu’une annulation ne laisse pas derrière elle un bloqueur de clic invisible ni ne retire une superposition de remplacement.
• Les scripts de plugins gardent leur sémantique d’achèvement existante : leur retenue de veille dure jusqu’au règlement ou à l’annulation, même pour une promesse qui ne se règle jamais. Les scripts de plugins et les actions de frappe longues n’héritent pas de l’échéance de capture.

Aucune nouvelle dépendance, aucun changement de permission ou de CSP, et rien n’a été tronqué dans le transcript ni dans le scrollback.

Comment le constater vous-même

Le parcours d’acceptation est volontairement manuel :

1. Ouvrez la même conversation dans deux fenêtres, réduisez-en une, streamez une longue réponse. Tapez dans la fenêtre visible, puis restaurez l’autre — les deux doivent afficher la réponse complète.
2. Appuyez sur Stop dans la fenêtre visible. La sortie annulée ne doit pas reprendre quand vous restaurez le pair.
3. Activez « Read replies aloud » dans les deux fenêtres : les pairs réduits restent throttlés, et la progression achevée ainsi que la réponse finale sont tout de même énoncées une fois.
4. Démarrez une conversation vocale dans une seule fenêtre : le stream du pair ne doit pas interrompre sa capture ni sa lecture.
5. Rechargez pendant un stream : la récupération conserve le dernier texte, y compris la queue silencieuse après que le fournisseur a cessé d’envoyer.

Quand vous le remarquerez vraiment

Trois situations : un portable laissé à surveiller une tâche longue, ceux qui gardent la même conversation ouverte dans deux ou trois fenêtres pour comparer, et ceux qui lisent la documentation dans l’aperçu intégré en l’annotant.

Cela ne rendra pas votre modèle plus rapide ni vos réponses plus courtes. Cela laisse simplement les fenêtres que personne ne regarde se taire.

Peut-on l’utiliser aujourd’hui ?

Les deux changements ont été fusionnés sur main le 4 novembre, après le point de release v0.22.7 — donc, à l’heure où ces lignes sont écrites, ils ne sont pas dans une release ; l’article sur la v0.22.7 couvre ce qui est bien sorti. La latence de frappe du bureau a sa propre analyse, et si ce qui vous intéresse vraiment est d’être prévenu quand quelque chose vous attend, le guide de l’attention et des notifications est le côté réception.