kicad-developers team mailing list archive

[Alex G <mr.nuke.me@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
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.

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

iQIcBAEBAgAGBQJMseEhAAoJEL0kPHNPXJJK3ZcP/0uHQlxoQ1c8C6dCxmMsNpTn
vmLHMNqk/pnyJh3zWX+i8dzFvh/G47a7RWTpHMD8kBmQXwPR8zKpQPfKsihu42E8
/XOuIoQxPiKQ6KECBG8IkQE0IY+AdzDaHXVeggJ0vK08s6Bf+hC0hipTccXe2dJG
utglRPPauTqQL4/jGaWgyC0CaOQ88Hf3Yo1ojHcu7ZBOAsNz+P3R9UK9jbU7Q1gA
hIgKV5gmInlOkB41ODD18BHFkHXXWrbqpM4Qs1b1YkXz9NaS60OrxQ9f7ZBmWZMg
5aPYvmR2O2lvcNe4oJwnnNwoca3/qqB3gL/wttSkyhDSQVEsXhCFaaADGZbNWRMR
C4KU05I/ZrPvmZgXQh9f6qrdP1iRU6labZnvt1NFpSuxeLO25l/KVWwkKR5Irkdv
X83ds//cXzkjwrXt4BULehG/fTV/gG8pfj+H5BHg3p0gDpuwM3W5l0b+biITbVYP
nD9TGMPMJrM+xlVJeJT4zYsZRsmcca87PeIFsNth7nJvV63/8MOjt4iUEnK5vWW7
txN/E8NApUzcQD5ThX/kYcxSx76znPnzJ/iPzn+dT0U/T9dZKLro7TvCiQlmOiWs
ttwmM7YF6+GcTu2Y/OyqZWQuFdWNXQThKLiGzTq+gNBccThxnfIJH1Q0ZQxMaA1k
AfIVv//3UGD61Hcc/4EO
=AiLX
-----END PGP SIGNATURE-----