← Back to team overview

kicad-developers team mailing list archive

OpenGL rendering for kicad


Hash: SHA1

After getting positive responses about GL rendering in other threads,
I'd like to put forth some general ideas about implementing it in kicad.
Also, please name any new ideas; it makes it easier to refer to them. :P

Safe OpenGL;
Because of the video driver mambo-jumbo, we shouldn't expect to use
anything but the most basic OpenGL. If we go this route, than any GL
call made will be implemented and callable. We don't have to worry about
extensions not being present, and risking to crash the program.

Rocket-boosted OpenGL:
Once the safe rendering path is in place, there's nothing stopping the
implementation of a secondary path that uses any exotic OpenGL extension
imaginable. The truth is, a board is a very dynamic entity; new tracks
are added, others are deleted, things are moved around. Keeping
everything in sync without having to resend the entire board data might
require some handy extensions (I say might as a GL noob would). If a
user works with complex enough boards, than he might want to take the
effort to make sure the video driver is properly installed and he can
use the full muscle of kicad, while casual users will find kicad working
just as before, or a bit faster.

Error recovery:
In my experience with OpenGL, there may be uncomfortable moments when
something goes wrong in the driver, and the GL context is lost. How can
kicad recover from such an error?

pcbnew first:
Notice how I talked about boards and tracks when justifying myself. I
think pcbnew should be the first to get a facelift.

Reuse of existing code:
The 3d viewer already has code that can draw tracks, a few other layers,
and turn them on and off. It also uses Safe OpenGL. Other than the
comment scarcity, it's an excellent starting point in my opinion.

It's in development:
What would the best way to work this out be:
a) a separate branch on launchpad
b) an "experimental" part of kicad in the main repo
With a separate branch anyone interested could get commit acces, but
keeping things in sync with the main repo might be an issue. Option b on
the other hand eliminates this problem, but we'll bother the big boys
very often with patches.

What are your thoughts? I wouldn't even know where to start, but I hope
after some brainstorming, designing, and plain neuron-burning, we can
come up with a workable plan; that is, if enough people like the idea.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


Follow ups