Re: gdk double buffering

[Owen Taylor <otaylor redhat com>]

Hi - 

A few notes you might find interesting:

 * There was a long thread on the render xfree86 org mailing 
   list discussing similar topics - I can't find a archive
   of the full thread ...

    http://www.mail-archive.com/render xfree86 org/msg00700.html

   is somewhere in the middle of the thread. 

 * An important simplification that can be made is that you
   almost never have operations involving _two_ separate
   toplevel windows that you have to make atomic.

   The list of things that need to be handled in typical
   operation is surprisingly short.

    - toplevel window move
    - toplevel window stacking order change
    - toplevel window show/hide (including changing desktops)

    - Contents of window change needing a redraw

    - User resizes toplevel window, forcing contents to
      adjust.
    - Contents of window change, forcing toplevel to
      spontaneously resize.

   The first three can be made atomic by simply saving the
   contents of every toplevel window on the server. (It's
   not unreasonable these days, and is needed if you want
   alpha-transparency for windows.)

   The fourth can be done entirely within the application,
   as GDK does currently.

   Only the last two are at all "hard", in that they involve
   things drawn by two different clients .... the window
   manager and the application. Basically, what you need
   to entirely fix those is the equivalent of 
   gdk_window_begin_paint(), gdk_window_end_paint(), but
   in the X server.

 * As for implementing double buffering by saving the operations
   rather than the results (the term "display list" is often
   used to refer to techniques like this.)

   It's certainly possible in theory. But I don't actually know
   of any current 2-D windowing systems that do it.
   My guess is that it would frequently save a bit of memory, 
   but the complexity would be prohibitive, and there is also the
   problem that while it would frequently save a bit of memory
   and be fast, it could be really expensive if the application
   drew lots and lots of primitives without starting over.

   As an example of the complexity - how do you store a
   "XCopyArea()" operation? You'd have to save the actual bits that 
   were copied since the source drawable could change between the 
   original operation and the point it actually occurred.

   You'd probably need considerable application cooperation
   to make it work reasonably.

Regards,
                                   Owen