Re: gEDA-user: pcb minor release, C++ and Gtk cleanup

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Fri, 2010-10-01 at 10:52 +0200, Armin Faltl wrote:
> 
> DJ Delorie wrote:
> >> Time to plug-in a graphics card? Almost any nvidia model would do.
> >>     
> >
> > I have a pair of Nvidia 9800 GT cards in my box, and yet the plain X
> > Lesstif HID still blows everything else away.  The cards alone are
> > only part of the pipeline.
> >   
> Do you have an explanation for this?
> 
> I thought that X is pure 2D and thus only primitive operations have to 
> be computed
> for each span of a shape. On the other hand, a full GL-engine will do 
> the 2D/3D transformations
> and span computations in hardware, so all the CPU has to supply is 
> untransformed
> vertices. What may slow down the GL version is transparency.

For each sub-composited layer group (one for each visible layer, plus
extras for polygons vs. lines within a layer), my OpenGL rendering code
uses a specific bit-plane on the stencil buffer. When it runs out (8
bit-planes on my card), it will perform a bit-masked clear of the
stencil buffer, wiping out dirty, but unused bits. (Often this should be
a complete, non-bitmasked clear, but not necessarily).

It is possible that the GL implementation you have cannot achieve an
accelerated clear with a bit-mask on the stencil buffer. On my built in
Intel graphics, clear performance is not great. Typically games don't
glClear many times per frame like this code does, so it might not be
highly optimised in the hardware. I'll also note that the Intel driver
code (in MESA) takes different code-paths for bit-masked and
non-bit-masked clears on the stencil buffer.

The speed you see "might" be in perception, rather than frame-rate. It
is entirely possible that the GL implementation (which has a slightly
different invalidate / expose model than the Lesstif / stock GTK HIDs)
may introduce extra latency.

I find the GL speed increase to be noticable for really huge boards
which otherwise bog down the GTK hid. They would probably bog down the
Lesstif HID too, but this might be card / X-server driver specific. I
got the impression that 2D X11 drawing calls are not highly optimised /
accelerated any more on Intel hardware with newer drivers.

> One big factor may be the R-tree acceleration built into the X 
> implementation.
> This will be difficult to emulate, if one wants to use display lists in 
> GL. Otoh
> a sensible GL implementation will do frustum culling - so why?

My implementation keeps the R-tree stuff. I don't use display lists or
permanent vertex buffer objects or anything fancy. I use a vertex array
(IIRC), to avoid the call overheads of immediate mode, but otherwise
feed geometry to the GL side in a very similar way to the other HIDs
making 2D calls. Frame by frame. We could do better with OpenGL if we
cached vertex arrays for layers not currently being edited.

We can't cache everything all the time though, as zoom level has a huge
effect on the number of primitives required to approximate curves.
(Board primitives, e.g. round-capped lines, have a lot of curves!). It
would become infeasible to create a vertex array of the whole board
approximated at "the" highest zoom-level.

Complex polygons are a win on my branch, as it features a "better"
rasteriser (stolen from cairo), and this appears to be faster than using
the no-holes dicer for rendering. This is less evident since I added a
cache for no-holes polygons in the core, but is useful for interactive
drawing. I can't recall whether I rasterise the whole polygon (complete
with holes), or use a masking technique with the stencil buffer to
"render" the holes first. I think the latter (perhaps a hold-over from
when I was using the GLU tessilator which got very slow with complex
holey polygons).


Best regards,

-- 
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