[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: double buffering in gschem?



>    Is there some way to enable double-buffering of some sort, or 
> something along those lines, in gschem so that the whole sheet isn't 
> redrawn over and over during panning with the scrollbars?
> 
>    I know X11 can do it (I've done it in Xt apps ages ago) but I don't 
> know how deeply that stuff is buried underneath gtk.

For those who don't know, there are a couple of ways to make redraws
cleaner when scrolling or exposing.  This is more of a primer than a
gschem-specific solution, since I don't know what api gschem uses for
its graphics.  PCB uses the gdk or X11 level stuff, so it has access
to the raw screen for these types of optimization.

When scrolling, the key is to use a blit to copy the existing screen
to the new location, and only redraw the new part.  For exposures, the
key is to only redraw the exposed part.  Both of these are similar, in
that you want to set up a clipping region for the new parts, clear
that, and redraw that.  That way you don't see the whole screen
redraw, and it's potentially a lot faster if you can reduce the amount
of data you have to scan through.  However, if your scrollbars don't
correspond to an exact number of pixels per increment, you may
accumulate rounding errors, which would cause the occasional visual
discontinuity on the screen (I see this in Firefox occasionally).

Alternatively, you can do what the lesstif HID does, which is to
redraw the whole screen when the system is idle (i.e. done changing
things). It redraws the whole screen to a pixmap, then blits the
pixmap to the screen.  While you still redraw the whole screen, you
don't have to erase it first, so there's no visible flicker.  Also,
this gives you a free backing store for exposures - when you get an
exposure, you just blit that part of the pixmap (which you save for
this purpose :) to the exposed part of the screen.  The other
advantage is that you don't ever have to wait for the screen to "catch
up" to your actions, because if it's not trying to update the screen
each time, *only* when there's nothing else to do.

There's always the option of true double buffering, but that's not
always faster than the other options since you always draw the whole
screen each time you want to change anything.

The other option is to use GLX to render your "wireframe" schematic on
the screen.  You're still updating the whole "screen" each time, but
you've got dedicated hardware doing the heavy lifting for you.


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user