|
|
@ -95,7 +95,21 @@ Core wayland protocol |
|
|
|
|
|
|
|
|
|
|
|
- xml based description instead? |
|
|
|
- xml based description instead? |
|
|
|
|
|
|
|
|
|
|
|
- actually make batch/commit batch up commands |
|
|
|
- Figure out if we need the batch/commit scheme and what to do |
|
|
|
|
|
|
|
instead. Since dropping the "copy" request, we have a race between |
|
|
|
|
|
|
|
copy from back to front and reporting damage. "copy" did this |
|
|
|
|
|
|
|
atomically, but copy is a rendering operation (wayland doesn't do |
|
|
|
|
|
|
|
rendering) and requires synchronization between server and client |
|
|
|
|
|
|
|
before client can reuse backbuffer. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The race condition happens when a client copies new content into |
|
|
|
|
|
|
|
its window and then, before the client reports the damage, the |
|
|
|
|
|
|
|
compositor then does a partial repaint (triggered by another |
|
|
|
|
|
|
|
client) that only pulls in part of the repainted area. It's only a |
|
|
|
|
|
|
|
one-frame glitch, as the client will submit the damage and the |
|
|
|
|
|
|
|
compositor will repaint the damaged area next frame. And ideally |
|
|
|
|
|
|
|
clients should do all rendering as early in the frame as possible |
|
|
|
|
|
|
|
to avoid this race. |
|
|
|
|
|
|
|
|
|
|
|
- auth; We need to generate a random socket name and advertise that |
|
|
|
- auth; We need to generate a random socket name and advertise that |
|
|
|
on dbus along with a connection cookie. Something like a method |
|
|
|
on dbus along with a connection cookie. Something like a method |
|
|
|