Hi Marco,
--- In kicad-devel@xxxxxxxxxxxxxxx, "emmedics4" <marco.serantoni@...>
wrote:
Have you tried to set GTKCAIRO_BACKEND=gl in your enviroment with
Cairo/wxGC ?
Interesting could be are also:
GTKCAIRO_GL_DOUBLEBUFFER=(0,1)
No one had the time to try it ?
GTKCAIRO_BACKEND=xlib changes anything ?
Tried it - but doesn't change anything, I think I need to compile it with Glitz support - howewer Glitz seems to be *experimental* - the last snapshot is from 20-May-2006 (?). The other question is, if calling OpenGL over Cairo is not too much overhead. OpenGL itself is already pretty powerful - most primitives that we need are already included. I'll add an fast arc support.
You forgot something also Paths.
I don't want to expose the paths to the user, I'd rather like an automatic support for it by the GAL. Currently I'm finishing a path when the line size / color is changed.
OpenGL has a much better feature - Display Lists - you can keep this way a complete component in the graphics card RAM inclusive transformations. I just need to figure out a good structure to support it.
--------
Wayne:
I previously mentioned that I would being willing to work on this after >the next release. I'm more than happy to let you take this on if you >have the ambition and the time.
I've written already a lot of code, thus I think it makes sense to continue. Of course I need help to build in the new class into KiCad.
If you are going take this on, please make sure that you create a robust >base GAL object first. If I still see the global pointer variable ActiveScreen anywhere, I would consider this a serious design flaw.
The GAL will be an abstract class, from that is a CairoGAL and a OpenGlGAL derived.
The first class derived from your base GAL class should be one that >incorporates the current drawing code which should be used as the >default until the new and improved GAL objects are implemented and >validated.
The problem is that the current code is not object-oriented - gr_basic seems to be converted from ANSI C. I'd like to have it clean the first time and would implement new draw(..) routines for the particular class (the old Draw(..) method should be kept to be backward compatible). Then I'd try out the new code for eeschema as a starting point.
Good Doxygen comments are going to be important so that the rest of the >developers know how to use this new GAL object. Thank you for your >efforts.
Of course - however I need some time - hope to have an alpha version ready in the next weeks. Some basic benchmarks with circles / lines work already, next goal is arc drawing.
BTW: That's the programming style I'm using for all my stuff (very similar to the typical Java style):
http://geosoft.no/development/cppstyle.html
