[Fwd: [gtk-list] Re: speeding up redraws]

[Stefan Wille <wille netlife de>]

How about adding this to docs/developers.txt? I suppose
every widget writer will want this information sooner or later.

Stefan

---

• From: raster redhat com
• To: gtk-list redhat com
• cc: otaylor gtk org, nuke bayside net
• Subject: [gtk-list] Re: speeding up redraws
• Date: Mon, 18 May 1998 17:40:25 -0400 (EDT)

On 18 May, Owen Taylor shouted:
->  
->  <nuke@bayside.net> writes:
->  
->  > i'm looking into speeding up the redraws in gtk. i'm pretty sure most of
->  > the time is spent loading the X server by clearing and redrawing entire
->  > widgets when only part of them needs the draw. honestly, i don't know how
->  > a toolkit can tell the difference. this kind of thing happens most
->  > noticably on scrollbars, buttons (especially in testgtk- try opaque moving
->  > a window over those buttons and watch them blink and redraw), and text
->  > that is actually being modified but is on the same line as text that is
->  > (selection, inserting).
->  
->  There are two things you are discussing here, speed and appearance.
->  These are somewhat separate (though related) issues, and I think
->  your complaint is more with the second one. But I'll cover
->  both.
->  
->  The most important thing to speed up GTK's redrawing is expose event
->  compression. If you opaque-move a window over a GTK window, the X
->  server will probably queue 5-6 narrow rectangles into GTK's queue
->  before it can process the first expose event. If these rectangles are
->  handled one-by-one it must redraw each button (etc.) 5-6 times. If it
->  instead combines them into one big rectangle, it only has to do this
->  once.
->  
->  The trickiest part of this is figuring out when to combine areas
->  or not. (A simple bounding box can increase the expose area
->  greatly - though Xt appears to do this) Various solutions
->  have been proposed - for instance microtiles.

hunt event queue for all expose events for the current window if an
expose event is found ont he queue - if any exist - take them off the
queue, and concatinate the "rects" ( i have a routine i wrote for E to
concatinate clip rects for the shape masks before it goes to the server
- seems to work, but it optimised for shapes - woudl work for expose
events too where adjacent rects will become one larger rect creating a
list of rects preferring them to be in horizontal strips if complex).

->  Expose event compression is a global thing that needs to be
->  added to GDK, not to individual widgets. 
->  
->  But no-matter how fast things are drawn, if you clear then redraw,
->  there is always a chance that the cleared state will be briefly drawn
->  on the screen, causing flicker.
->  
->  Flicker avoidance can be handled several ways:
->  
->   - Draw each pixel only once. If no clearing is done in advance,
->     then no flickering will happen. But this can complicate the
->     display code quite a bit - you need to explicitly fill any
->     areas that don't get drawn otherwise with the background
->     color - and is actually impossible when you text is involved.
->     (The clear isn't necessary when handling expose events, but the
->     same drawing code is used for handling other cases like resizes 
->     or changes of state where non-empty regions can become empty regions)
->  
->   - Draw only the affected regions. If you only redraw the portions
->     within the expose rectangles, then no flickering will happen
->     on exposes (though this won't help resizes). You can either
->     do this by doing the clipping yourself (complicated), or 
->     by setting the clip region for the GC's you are drawing with.
->     (Somewhat expensive because something like a button may use quite
->     a few different GC's)
->  
->   - Use a backing pixmap. Draw everything to the backing pixmap,
->     then copy the result onto the screen. This is often the
->     simplest method, but is expensive in terms of server memory.

copy onto screen? why bother. it's already on the server.. set as a
background pixmap and lett he server redraw for you (MUCH faster - no
extra server traffic involved). If you are ever goign to use a pixmap
for anything.. and it's goign to fill a window.. thsi is "the thing to
do" (tm) :)

->  So, that may give some idea of the issues involved, and where
->  you might start.

I like your idea of concatinating the exposes. that probably will igve
the best speedups (if on a slowish serevr but fastish box)- on a "slow"
cpu but "fast" server/gfx card it might not actually give any
benefits.. but that remains for speed tests to be seen. (ie a 486Dx2-66
with a PCI bus with a MilleniumII 8Mb PCI tagged on.. the Millenium
prolly has more grunt than the cpu does... okay minor exaggeration ..
:) )

->  Regards,
->                                          Owen
->  
->  

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/ 

-- 
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null

---