Re: GTK+ redrawing strategy: backing store, double buffering
- From: Owen Taylor <otaylor redhat com>
- To: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- Cc: gtk-devel-list gnome org
- Subject: Re: GTK+ redrawing strategy: backing store, double buffering
- Date: Tue, 07 Oct 2003 11:19:39 -0400
Here's a a mail I sent to forum xfree86 org on the subject explaining
of why I think doing it in the toolkit is a bad idea:
===
From: Owen Taylor <otaylor redhat com>
To: forum XFree86 Org
Subject: Re: [forum] Snappy GUI response
Date: 04 Jul 2003 14:35:16 -0400
On Fri, 2003-07-04 at 14:05, Mark Vojkovich wrote:
[...]
> I advocate backing pixmaps for as many windows as it
> makes sense, and no expose events on them. Not only is this
> extremely fast even if server is rendering in software, but
> it looks great (you don't see redrawing). That is, save all
> your expensive rendering, don't keep redrawing it. Put it in
> a pixmap and set it as the window background. There's also
> a good change this pixmap will end up in video ram rather than
> system ram.
Saving the full contents of each toplevel window makes a lot
of sense these days. Doing it in the toolkit doesn't:
* If the windowing system saves the full contents of each
toplevel (see below for why that works better), then you
double the 50+ megabytes of memory you are using by
saving the full contents of each window in the toolkit.
The directfb and OS X X servers are current examples of
X servers that save the full contents of each window.
* The windowing system, if it has the full contents, can
do neat things like per-window alpha channels.
* The windowing system is generally in a much better position
to know when to dump the window contents and ask the app to
redraw them. (because you are out of memory, because
the window is fully obscured or on a different desktop, etc.)
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]