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

[<nuke bayside net>]

On Mon, 18 May 1998 raster@redhat.com wrote:

> 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 are there any specific reasons why making everything a backing pixmap
and letting the server take care of everything could be bad? i guess i'm
just being too picky about the redraw code, but i couldn't help but think
we're inferior to windows in some form... after using word97 on my
father's win95 machine and seeing its
detachable/dockable/windowable/resizable/etc toolbars and how well all the
widgets interact with each other (including very fast opaque
resizes/moves), i wondered how it all could be done in gtk.

> 
> ->  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 ..
>:) )

that's about the description of my box.. nice p166, but relatively crappy
mystique/2mb.

> ->  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
> 

 _        _  __     __             _ _                                  _
|        / |/ /_ __/ /_____         |       Nuke Skyjumper               |
|       /    / // /  '_/ -_)        |         "Master of the Farce"      |
|_     /_/|_/\_,_/_/\_\\__/        _|_           nuke@bayside.net       _|