gEDA-dev: [Re: is all EDA as bad as gEDA/pcb?]

Peter Clifton pcjc2 at cam.ac.uk
Mon Dec 10 22:28:26 EST 2007


On Mon, 2007-12-10 at 22:04 -0500, Dan McMahill wrote:

> That said, I'd like to think that perhaps there will be a period of 
> stability.  Ben and DJ have fixed a bunch of bugs lately and there is at 
> least one which I know of that I really need to fix.
> 
> Really we could use more help though.  If anyone cares to kidnap DJ and 
> make several clones that would be a good start!

Wouldn't that mean we get a vastly improved Lesstif HID?? ;)

I've been bashing at some of the drawing performance bugs Ben found, and
we think we've got somewhere in identifying why its slow.

For example... lots of redraws are being forced for each object being
moved. A "Draw ();" call is made after every object.

No bounds to invalidate seem to be stored in the various variables, (all
are 0), but this doesn't matter, as both the Lesstif and GTK HIDs ignore
the bounds, and invalidate the whole screen.

The Lesstif HID does this with an idle work function which is only added
if not queued to run already.

The GTK HID forces a redraw immediately. (BAD).

I've got a patch to make the GTK HID use an idle function too, however
this exposes a rendering glitch, where pads, lines etc.. are cleared to
black on the screen where they "used" to be at the very end of a drag
operation, before the real redraw function is called. This nasty glitch
probably ought to be fixed before I push the idle-function patch.

Another patch removes the Draw(); functions from move.c, although I'm
weary that I need to figure out just exactly _where_ the final redraw
_SHOULD_ be triggered after the operation completes. It seems to happen
at the moment.. but I'd like to know why!

Best wishes,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



More information about the geda-dev mailing list