0

On systems with a compositor, a windowed application must render into an off-screen buffer, which is then submitted to the compositor for composition and presentation. How does displaying a windowed desktop work without a compositor?

Suppose we have a 3D application using double buffering to render into a window, fully redrawing on each frame. This is my understanding of the process of presenting a new frame:

  1. Application submits a frame buffer for presentation.
  2. Compositor receives the buffer.
  3. Later, the compositor composites all the windows into the screen's back buffer.
  4. Compositor swaps the screen's buffers.

What happens after step 1 if there is no compositor? (For example, on Windows without DWM, or on an X server.) Clearly, something is laying out the windows and making sure they render in the correct position and order. How is that different from compositing?

Electro
  • 2,994
  • 5
  • 26
  • 32
  • Look at the **https://www.x.org/releases/X11R7.5/doc/compositeproto/compositeproto.txt**. It clearly states what does it mean for WM to support compositing. The "compositing" thing, just gives a WM, the application, more control about how it does... the compositing. How is that different from compositing, to you? – user14063792468 May 04 '22 at 02:05
  • That document concerns the protocol, but I'm interested in the implementation details. For instance, how is window clipping done without the Composite extension? (I'm curious because people talk about compositors inherently increasing display latency, but I'm not sure why that is or why it doesn't happen with a regular WM.) – Electro May 04 '22 at 06:52
  • Window clipping done with a rectangle intersections, as you expect it to be done. The final display is done to one-and-only front buffer, but only after all windows had submitted their willingness to change some visible properties. This is the simplest form of "compositing". – user14063792468 May 04 '22 at 09:09
  • What do you mean by that, that compositors increase display latency? – user14063792468 May 04 '22 at 09:12
  • By increased display latency, I mean that the display of updated window buffers may be delayed by one or more frames (even if a window buffer swap is requested well before the monitor's VBLANK period). At least with Windows's DWM, there is a notion of a "composition deadline". Missing this deadline means your new frame won't be visible on the next scanout, but there is no mention of a similar deadline existing when DWM is not used. – Electro May 04 '22 at 14:47
  • Only practical case, I can think of, of user have bad experience with the mentioned latency, is a high interactive programs. Such that presentation lags behind user input. My practical needs tolerate the 1-2 display lags. – user14063792468 May 05 '22 at 20:45
  • I think, through I can not prove it, that X11 protocol can request, or "turn off", WM compositing for the window. I do not know, if all WM's will support both modes on one desktop. I think, again without proof, that I can create window explicit, with compositing turned off. – user14063792468 May 05 '22 at 20:51

0 Answers0