gEDA-dev: gschem -- Datastructures

[Peter Clifton]

On Tue, 2006-08-01 at 15:00 +0200, Patrick Bernaud wrote:
[snip]

>   - what is your solution for objects in pages? I mean since you can
>     have several views on a single page, you can have different zoom
>     level on a single page for example.
> 
>     Every object is recalc-ed every time the zoom is modified and they
>     have only one set of screen_* fields.
> 
>     Are you somehow repeating the object hierarchy in VIEWs?
[snip]

I just produced a version of gschem and libgeda which _REMOVES_ the
locally cached screen coordinates from the object heirachy.

All recalc functions now only compute the world bounding box where this
was done before, and I expect many CPU cycles could be spared by only
re-doing this where necessary. (Many objects may still recalc it on
zoom)

I don't notice much difference on my PC, but to test, built a large
schematic (lots of FPGAs on a page), and ran both a clean gschem, and
the cache-less version under valgrind (to slow its redraw to stopwatch
measurable times).

For a full screen, 1280x1024 maximised gschem (less Gnome toolbars), a
redraw of the schematic triggered by "ve" (view extents), from a zoom
level got to by "ve", took around 64 seconds with CVS gschem, and only
62 seconds with my cache-stripped version.

I will acknowledge that this is the slowest operation for the CVS
gschem, and normal redraw may be improved from this point so long as
recalculations are kept to a minimum, however I think it is a good sign
that the cached screen coords are not amazingly critical.

My cache-less version isn't that cleverly implemented. Many bounds tests
_SHOULD_ now be performed in world coords, where my simple
implementation converts on the fly to SCREEN coords, then performs the
tests. (This should be a significant hit on CPU cycles for a schematic
with lots of objects).

I think that with a good refactor to ensure as much testing and drawing
ops as possible are done in WORLD coords, this will not affect the speed
too badly, if at all. (Floating point ops. should be cheap on PC
hardware nowadays, I'm not even going to say "modern" pc hardware).

I will even conjecture that the codebase will be more compact, and less
prone to redrawing glitches if this is done correctly, as the world
coords should be definitive with the exeption of mouse event driven
rubberbanding.


If the need / desire arises later, a caching system capable of keeping
multiple views worth of data could be implemented.

Comments?

Peter C.