kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Torsten Hüter wrote:
> 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. 

I recommend passing the base GAL class to the various Kicad drawing code 
instead of wxDC that is used in the current Kicad drawing code. One of 
the easiest places to start would be the schematic library item drawing 
code ( eeschema/classes_body_items.cpp[h] ). Then any class derived 
from the base GAL object could be passed the the Kicad drawing code 
which would make it easy to change GALs as required.

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

Be careful when designing the base (abstract) class. Take a look at 
wxDCBase in the wxWidgets source for a good example of how to implement 
the base GAL class. Notice that the public non-virtual drawing 
functions do nothing more than call the private virtual functions ( 
public DrawLine() calls private DoDrawLine() ). All the work is done by 
the DoDrawLine() method for each derived class.

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

It should not be very difficult to create a wxDCGAL class derived from 
the base GAL class as a wrapper for the current drawing code (this is 
what I was planning). We know this code works acceptably on all 
supported platforms and this would be the least disruptive path. I 
don't want SVN HEAD to be completely unusable until the new drawing code 
is complete. I suppose we could create a GAL branch in SVN and merge it 
into HEAD when (if) it is ready. Using wxDCGAL would give us a fail 
safe in case the new GALs fall short of expectations and make the 
current drawing code much more maintainable should we need to keep it.

Wayne

> > 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
>
> Bye ..
> Torsten