Re: gdk double buffering
- From: Owen Taylor <otaylor redhat com>
- To: Wouter van Kleunen <w a p vankleunen student utwente nl>
- Cc: gtk-devel-list gnome org
- Subject: Re: gdk double buffering
- Date: 13 Mar 2003 09:03:37 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]