diff options
author | Kristian Høgsberg <krh@bitplanet.net> | 2010-08-02 12:45:38 -0400 |
---|---|---|
committer | Kristian Høgsberg <krh@bitplanet.net> | 2010-08-02 12:45:38 -0400 |
commit | c37c57aec7128be829fa80640d7236ca0a4b56fc (patch) | |
tree | 7a90922ae4eeb8b3b34a175124e8cdf7177ad35a | |
parent | 723b2852d22851d0cf1dfe737f0fc375cc692f12 (diff) |
TODO: Add a few lines about removing commit request
-rw-r--r-- | TODO | 16 |
1 files changed, 15 insertions, 1 deletions
@@ -95,7 +95,21 @@ Core wayland protocol - 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 on dbus along with a connection cookie. Something like a method |