<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 1:20 PM, Michael Forney <span dir="ltr"><<a href="mailto:mforney@mforney.org" target="_blank">mforney@mforney.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 23, 2015 at 12:10:02PM -0700, Bill Spitzak wrote:<br>
> Seems like the wl_display.sync() can do the job. The compositor may send<br>
> several configure events, that is harmless. Just use the last one.<br>
><br>
> A compositor *may* try to predict where the window is going to be mapped.<br>
> This prediction may change due to methods such as set_app_id. It may also<br>
> change due to actions by other clients or the user which can happen at any<br>
> time (and thus there is no way for the client to put a call after them).<br>
> All of these would send configure events. It is ok that it may send a lot<br>
> of them. Just respond to the last one.<br>
<br>
</span>I think that this does not completely solve the problem.<br>
<br>
For example, suppose I start client foo, and I have a special rule that<br>
puts foo windows on some other screen. Since the compositor does not yet<br>
know that the client is foo, it sends a configure event to re-tile the<br>
windows to make room for the client on the current screen. It then<br>
receives the set_app_id request and realizes the window should have been<br>
placed on the other screen, so it configures all the windows back to the<br>
way they were before.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The foo client may not have any problems because it is in the middle of<br>
a wl_display_roundtrip, but the other clients may receive the first<br>
event, but not yet the second, causing them to redraw for a new size.<br>
Then they see the original size and redraw the original frame again.<br>
This would cause flicker on the primary screen, even though nothing<br>
changed about those windows.<br>
<br>
I suppose that if I delay retiling the other windows until I have<br>
received the initial buffer from the new client, this wouldn't be a<br>
problem, but it would essentially cause the new client resize and the<br>
existing client resize roundtrips to happen sequentially rather than in<br>
parallel. I'll have to do some testing to see if this actually causes<br>
any noticable delay/flicker when retiling due to a new client.<br></blockquote><div><br></div><div>I think it is a requirement that it be possible to avoid any such mistake entirely. It should be possible to always draw a 100% perfect screen image. Only if the latency is unacceptable should it then resort to flicker.<br><br></div><div>I think this could be done in the way you say if the compositor then blocks until it receives updated buffers from all the other clients that get resized. This would match how you have to handle the user moving the border between tiles: it has to block until it gets updated buffers from all clients that have a new size.<br><br></div><div>However you are right that this defers sending the configure events to the other clients until after the foo client has responded to it's configure event, when it certainly seems like it could send the configure events to all the clients simultaneously. I am not really certain this is going to be a huge problem (the foo client is certainly swapped in and ready to draw it's image) but it does seem like fixing it would require a commit request of some type.<br><br></div><div>I'm thinking now that this is occurring often enough that it would be cleaner to build such commits in at a low-level into wayland. Rather than the commit message on wl_surface, and the new "axis finished" events being sent the other way, there is a single request and event on wl_display, that indicate a break between atomic blocks of changes (also quite a few requests and events, such as the sync and ping/pong would imply breaks). This would avoid adding these extra events/requests to all the api's, and also free the clients and compositors from having to deal with "intersecting" blocks where events that require commit-type-A are mixed in with events requiring commit-type-B.<br><br></div></div></div></div>