Unresponsive applications

[William Swanson]

2011/9/22 Bill Spitzak <spitzak at gmail.com>:
> It is IMPOSSIBLE to
> synchronize the drawing of the contents with the border unless they are
> drawn by the same process, and I do wish the people who keep suggesting
> elaborate many-round-trip sync protocols where they keep adding more and
> more steps and latency will realize this.

You keep saying this, and it is simply not true. If the compositor has
enough information to render a pixel-perfect desktop every frame, it
certainly has enough information to draw pixel-perfect borders as
well. See how simple the pseudocode is:

draw_compositor_frame()
{
 foreach (window in windows) {
   copy_buffer(window.buffer, window.x, window.y, window.w, window.h);
   if (window.needs_border)
     draw_border(window.x - 8, window.y - 24, window.w + 20, window.h + 32);
 }
}

In other words, the compositor can use the information it already has
to draw pixel-perfect borders every frame with zero additional
latency. Client applications present their buffers to the compositor
exactly as they do in Wayland now; there is no additional complexity
apart from the rendering code in the compositor.

Now, do you actually _want_ the compositor drawing the borders? I
don't know; there are good arguments on both sides. My point is that
either way is perfectly feasible from a purely technical point of
view.*

-William Swanson

* Actually, doing the Windows Vista "glass" effect requires the
compositor to get involved with borders. The glass is not a simple
alpha-blending trick; it actually involves blurring the contents of
the windows underneath. The compositor is the only one who can perform
the blur, since it is the only process with access to the
partially-composited desktop on each frame.