Re: gEDA-user: Ben mode feature request

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Sun, 2010-10-31 at 22:29 +0100, Stefan Salewski wrote:
> On Sun, 2010-10-31 at 19:30 +0000, Peter Clifton wrote:
> 
> > 
> > /me goes back to writing kernel profiling driver for intel GPUs to
> > squeeze more framerate out of PCB+GL.
> > 
> 
> Indeed I wonder why framerate is critical -- is this only for rotating
> the board in 3D view?

Not just that, but any interactive rendering operation will repaint
areas of the frame. I'm looking at moderately complex boards which can
only just reach 30fps. Many boards I've got as test cases will struggle
to do 10fps, or 5fps even.

Above approx 10fps is usable, but you really want 15-20 upwards.

Part of the problem is CPU, part is GPU. The 30fps I'm talking about
above is JUST graphics render, without any overhead of changing the
objects being rendered. That represents the best case frame-rate with
caching of static geometry.


> For other editing operation most of the board
> should be statical, so we have the static background which we copy for
> each frame to the display, and only one element (footprint, trace, ...)
> which needs real new drawing for each frame.

PCB (and my GL code) is not smart enough to make use of limited damage
regions, and redraws the whole frame every time. Yes, we could do
better, but there would still be memory copies involved.

If we were _really_ clever, we could use the double buffering of frames,
and compute damage VS. the frame _previous_ to the frame on screen, (in
the back-buffer). It is already a frame behind, but if it can be updated
to current, it saves copying the front-buffer as your rendering start
point.

(Alternatively, you would have to have a back-buffer copy rather than
swapbuffers for each frame).

>  (When I started my toy
> gschem clone in Ruby my fear was indeed a sluggish display, but with
> smart cairo layer buffers there should be no problem.) 
> 
> Of course you are very smart, so I seem to miss something...  

The update code is sadly pretty dumb.

What I wanted to ensure was fast, would be panning / zooming, which
involved full frame redraws. I want to optimise that first, _then we can
make the editing small areas case lightning fast.


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