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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
