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

Re: gEDA-user: Ben mode feature request



On Mon, 2010-11-01 at 00:19 +0100, Stefan Salewski wrote:
> Unfortunately there are not much examples, at least not for clever
> buffering with cairo.

No, although gerbv actually seems to do a good job in this regard. IIRC,
just redrawing edges which need repainting after a pan.

Zoom can be fudged by stretching your current image up when zooming in,
or shrinking it (then repainting the whole screen when you get a moment)
when zooming out.

With GL, I was looking at storing images of each layer in texture
memory. Sounds good.. but I can't store much bigger than my native
screen size due to hardware limitations on texture size.. I'd need to
split it up into tiles smaller than the hardware limit to be sure of it
working at high resolution. (And of course, different chips will have
different limits).

> My guess: For zooming we have to do a complete redraw of the visible
> area. For panning: I intend to draw to a buffer, which dimension
> increases when we zoom in, and copy a part of that buffer to the smaller
> cairo drawing area of the GTK window. So panning is fast, only copy.

Fair enough.

To be honest, I'd love to instrument a version of PCB with zoom /
panning / ... tracked, and have some testers actually work with it for
various common tasks:

1. Editing a board
2. Making changes to an existing board
3. Populating / Debugging the board, with reference to the PCB for
finding connectivity.

Those would all be in my common work-flow, but I've not had cause to
design so many boards recently. (Also, I might be biased by having
preconceptions about the test).


> Moving a symbol: Mark that symbol as invisible, draw buffer, copy area
> of buffer to window, draw moving symbol to window. For each new frame:
> Copy area of buffer, draw that moving symbol. I guess that may work,
> even for slow Ruby.

As long as the graphics routines are fast (which they ought to be),
overhead ought not to be too bad.

> Of course for PCB and OpenGL all is more difficult.
> Recently I was wondering if that Clutter library may be useful, but I
> think that will make all more complicated.
> 
>  http://www.clutter-project.org/ 

Gnome shell / Ubuntu unity use that. I'm not sure if its clutter's
fault, or the underlying "mutter" window manager (which uses clutter),
but it isn't fast enough.

That said.. it might be fun, but I don't think it is really suited to be
the PCB application's canvas.


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

-- 
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!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)



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