kicad-developers team mailing list archive
Mailing list archive
Re: Graphics Limits … Windows & CAIRO
Hi Marco & Lorenzo,
>I'm still stuck but i can wait, which is the deadline for the shipment >of the GAL in the trunk ?
>I'm proposing this approach because is a viable way to start to redesign >the drawing code before GAL is ready.
Well, I'm sure that still needs a while; but I think it should be a smooth transition - and the old code will be there for a while. Dick has proposed a painter class for this purpose - it's a collection of all drawing routines for board/schematic objects. I could imagine one of the next steps would be to implement this class - We have just to discuss first how we do it the best way.
My question is why you're stuck; does the old code not run well on OSX?
Another thing is that we should't build up two competing solutions; is the redesign on the same road?
>I'm almost scared to fight with a new Custom Graphics Abstration Layer.
>I'vent much time to dedicate and i'm afraid that debugging and correct >implementation on the platform will require months of frustrating work >to make it just work, this situation summed with the frustrating work i >were required to do for making it work until now (wxOverlay addition) >and added those months of Freeze the situation begins to approach the >limits of the allowable for a Gratis/Free work (as Dick reminds us >frequently).
Shure, but I've investigated lots of hours into this project (thus indirectly money). If someone likes to have OSX supported, he has to help me or - like Dick has written - organize/finance me a MAC.
Perhaps even a remote login would help.
I'm sure we can find a solution, when we're at this point.
The GAL is in my opinion not a custom layer. Like the name says it's an abstract approach; something that should be easily to extend. My goal is to solve some inherent problems of KiCad - that we get features like layer dimming, transparency, stepless zoom, smooth panning, a consistent vector algebra etc.
I'd assume there has not much to be changed on the OSX platform - because OpenGL is multi-platform and Cairo should also run well. That's why I've choosen these two backends.
> CAIRO is a showstopper on Linux without gallium (i.e. hw acceleration),
> so the problem remain...
Well, I've found it not that bad. It depends how you're using cairo. I think the wxGCDC approach is pretty inefficient - because the paths are not used optimally.
>The 'main' problem is that consumer cards (and drivers) are usually
>*awful* in performance in geometry-mode (i.e. wireframe, not filled
>polygons), just look at the opengl demos (which usually have a framerate
>counter and a filled/wireframe switch).
I don't believe that this statement is really true today. Simply because now graphics cards are general purpose computing units (GPGPUs). Even my notebook has 48 stream processors and it's rather a low end GPU.
Geometry is programmed and computed by the geometry shader for instance (when the fixed pipeline is not used).
A lower end consumer graphics card like the Radeon HD 7770 for ~100 Euro has 1280 GFLOPS. That should be really fast enough :)
At least the examples that I've tried with the OpenGL-GAL run pretty smooth. It gets interesting, when we're able to show some real boards with it.
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de