Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
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. 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? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
On Fri, 2010-10-01 at 10:52 -0400, DJ Delorie wrote: Do you have an explanation for this? Yes. Four monitors with one desktop means there's a lot of overhead I still have only one monitor, and I wonder how useful working with multiple monitors really is. Prices are not really high in these days, and power consumption is about 20W each, not too much compared with other hardware. I think the greatest benefit is: If your boss comes in, and on one monitor there is your source file, on the other a datasheet, on the other the running application, he will think: That guy is working really hard... But I am not really sure if multiple monitors are a real benefit, because for Linux we have multiple virtual screens/work spaces. Is turning the head really better than switching to another virtual screen? On topic again: May it be good to have multiple active working windows for PCB/gschem, so that we can have a zoomed view in one window, and the whole board in the other window, maybe on an other monitor. May look cool, but I am not sure how useful that is, and how difficult to implement. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
I still have only one monitor, and I wonder how useful working with Is it at least color? multiple monitors really is. Prices are not really high in these days, and power consumption is about 20W each, not too much compared with other hardware. I think the greatest benefit is: If your boss comes in, and on one monitor there is your source file, on the other a datasheet, on the other the running application, he will think: That guy is working really hard... But I am not really sure if multiple monitors are a real benefit, because for Linux we have multiple virtual screens/work spaces. Is turning the head really better than switching to another virtual screen? Most. Ridiculous. Thing. Heard. Ever. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
Andrew Poelstra wrote: 2. We need to have a minor release (1.99za?) to get all the little crap out of the pipeline before we break everything. And please, please apply as much of Peter Cliftons pcb version as possible before you start. It is not only about the openGL and 3D hack for visuals, but a huge bag of little useful improvements. Let's not loose them on the way. ---)kaiamrtin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
Kai-Martin Knaak wrote: And please, please apply as much of Peter Cliftons pcb version as possible before you start. It is not only about the openGL and 3D hack for visuals, but a huge bag of little useful improvements. Let's not loose them on the way. I hope this won't break the Lesstif HID. Peter's branch is still several times slower than elder GUIs on all my machines, which makes the GL-based renderer actually unusable for me. Kind regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: pcb minor release, C++ and Gtk cleanup
Hey all, The list has quieted down these last couple weeks. Last I heard, any significant work on pcb is essentially blocked, pending a migration to C++. And before that can happen: 1. DJ needs to assess the existing C++-compatibility patch. 2. We need to have a minor release (1.99za?) to get all the little crap out of the pipeline before we break everything. From there, we can fix up the Gtk HID and fix some of the weird bugs like Richard Neill's 'c' issue, then hopefully make some big changes, like OpenGL, restructuring layers, and new file formats. What's the status on these things? Is there anything I can do to help? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
On Sat, Sep 25, 2010 at 11:37:12AM -0700, Andrew Poelstra wrote: The list has quieted down these last couple weeks. Last I heard, any significant work on pcb is essentially blocked, pending a migration to C++. And before that can happen: Hey, cool. I have been mostly skimming so I must have missed this in one of those threads that wandered wayy off topic (you know that the 100th message titled TO92 land pattern has probably covered everything from polygons to XML). Anyway, if there's a code sprint to convert the core of PCB to C++ I'm in. I've almost done it a few times myself. -- Ben Jackson AD7GD b...@ben.com http://www.ben.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
The blockage at the moment is me. I've got a ton of work to do for Devcon, plus other things taking up time. By mid-october I should have time to do stuff again. My plan is to release pcb-1.99za just to clean up some segfaults and get the importer released so that project can be closed out. Then we can work on PCB 4.0. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
Anyway, if there's a code sprint to convert the core of PCB to C++ I'm in. I've almost done it a few times myself. Newell already did it, there's a patch in the tracker. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
