Re: gdk double buffering

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-03-13 at 22:45, Federico Mena Quintero wrote:

> For example, you could make GDK pay attention to VisibilityNotify events
> so that calls to drawing functions do nothing if a window gets
> FullyObscured. 

It's probably an hour or so of work, if that. I'm surprised nobody
has done it yet :-)

>  Or you could figure out if there is a way to get a
> window's real visible area from the X server without doing egregious and
> non-atomic things like walking the window tree --- then you could stick
> that into gdk/x11/gdkwindow-x11.c:
> gdk_window_impl_x11_get_visible_region().  Then make all the drawing
> calls pay attention to that. 

If such an extension was desired, I think the right way to do it is to
make it work a lot like VisibilityNotify, but have the events contain
rectangles like expose events. This allows you to avoid race conditions
_and_ roundtrips.

There might be an area that you didn't know was visible yet, and thus
didn't draw, but you'd be sure of getting an expose event in that
case.

>  This would help a lot, say, when you have
> a terminal scrolling a lot (think of a compilation cycle) and when the
> terminal's window is not even in the virtual desktop you are in --- my X
> server gets really jerky when VTE scrolls a lot in the background, for
> example, and it is a 1 GHz machine...

VisibilityNotify handling by itself would handle the other-desktop case,
of course.

(
In terms of why it's particularly noticeable for VTE... probably
multiple things going on here:

 - RENDER's software of compositing is really unoptimized and slow.
   By a factor of 10 or so in some cases. (I think I'm annoying
   Keith by repeatedly pointing this out, but it is worth being
   aware that it will eventually be fixed when considering
   architectural issues.)

 - There have been some bugs in VTE until recently that made it
   do a lot more rendering than necesary.

 - If you are using Red Hat 8.0, it's going to bump the priority
   of the X server, which turns out to be a really bad thing for
   interactive performance, opposite from what people expected.
)

> Remember that most of the speed problems in GUIs are perceptual, and
> hard problems like synchronizing the X server and apps are best left to
> the X server itself.  Once Xfree gets real transparent windows it will
> most likely keep backing store of its own for all windows, so a lot of
> these problems will be solved automatically.
> 
> I haven't found the time to use xmon or some other X traffic sniffer to
> see if GDK's drawing innards are doing something that could be
> optimized.  Right now it creates and destroys a GC for each temporary
> pixmap used for double buffering; I don't know if that creates X traffic
> or if Xlib is doing caching for us --- maybe it would be better to share
> a single GC for all drawables with the same depth?

I've never seen the GC creation and destruction show up on profiles
either of GTK+ or of the X server. (Remember, GC creation is 
not a round trip.)

But with the solid-area-compositing patch, I needed scratch GC's 
a _lot_ (once for each string, not for each drawn area), so that
patch contains a trivial addition of:

 _gdk_x11_visual_get_scratch_gc()

I wouldn't object if that part of the patch was extracted and used
for the double-buffer pixmaps. If it didn't help performance, it
would at least calm the nerves of people looking at X traces
from GTK+.

Regards,
                                                  Owen