kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Wayne Stambaugh wrote:
> 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.

Wayne, why do you consider writing 2 functions in order to get to a 
single destination a good design? Is C++ having problems?

What I see is a space vs. speed trade off. And we want speed. Is it 
more than this?

Dick