kicad-developers team mailing list archive
Mailing list archive
Re: OpenGL rendering for kicad
If you like, you can help me testing - I'm writing currently on something that's called "Graphics Abstraction Layer". There is a branch in the launchpad repository (kicad-gal).
However I've to upload a new version (I had trouble with cmake/wxWidgets 2.9.1). Currently I'm working on frame buffer object support for rubberbanding and loading of fragment/vertex shaders.
> 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> -----END PGP SIGNATURE-----
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
GRATIS! Movie-FLAT mit über 300 Videos.
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome