Giuseppe Bilotta <giuseppe.bilo...@gmail.com> writes: > Ah, good point. So Compton wouldn't break anyway, at worst it couldn't > use the feature reliably.
Having any reasonable Compositing Manager not work is a sign that the design isn't quite right. > Actually I'm not sure 2) would work reliably even in the WM == CM > case, if _any_ descendant can be put in the Auto list, since the WM > wouldn't be aware of geometry changes in nested windows, right? It would "work", in that the window contents wouldn't escape the bounds of the managed area, but it wouldn't be perfect. But, it wouldn't be any worse than we have today -- reconfiguring subwindows happens non-atomically, and so partial rendering adventures happen all of the time. Presumably the CM would track the geometry of windows in the Auto List and be aware of the change, repairing the screen in a subsequent frame. I'm starting to wonder if nested descendants in the Auto List is a good idea. Keeping the boundary between Compositing Manager and application at the top-level client window has proven pretty workable so far. Let clients be responsible for ensuring that their top-level window contents represent their desired presentation at all times. > However, if I understand the proposal correctly, the server knows > about the Auto list only at Present time, which would be too late. The Compositing Manager can monitor window geometry for any window it chooses, whether or not that window is in the Auto List. > Since the Auto list isn't likely to change frequently, would it be > possible to build it _separately_ from the Present call? A key part of the design is that the Auto List be tied to a specific presentation on the screen; geometry for the Auto List windows is reserved in that image. So, we need to synchronously update the Auto List and the presented image, hence tying them together. Given that the Auto List is a (probably small) subset of the top-level windows, sending it each time is probably simpler than creating a new resource to hold it. Even sending a few hundred window IDs per frame wouldn't be terrible. > Or maybe just require that the CM manually elect to get notified of > geometry changes for the windows they plan on putting in the Auto > list? That's far easier as it requires no additional X server code, and only a small amount of code in the Compositing Manager. > Then if I understand correctly Mode 1 could be implemented by delaying > the geometry change requests that happen after a Present request to > after the actual page flip (or whichever other time is deemed “safe”), You raise a good point here -- we want the client geometry change to be presented without any intermediate partial frames. I think the easiest way to manage that is to have the Compositing Manager take control of the display before the resize happens. It could be something as simple as blocking any resize request for a window in the Auto List and sending an event to the Compositing Manager to deal with the situation. How about this -- any configuration change (by a client other than the Compositing Manager) affecting a member of the Auto List would be blocked until a PresentPixmap request removes that element of the AutoList. Adding a member to the AutoList is sufficient to register an interest in the event. That would let us continue to allow arbitrary windows in the AutoList and ensure that no configuration changes occur while windows are on the Auto List. -- -keith
Description: PGP signature
_______________________________________________ firstname.lastname@example.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel