pbfy0 / visvis

Automatically exported from code.google.com/p/visvis
Other
0 stars 0 forks source link

Compatibility for pure OpenGl 3.1+ #26

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Since OpenGl 3.1, many OpenGl features have been deprecated. Examples are 
glBegin(), glEnd() and every function that could be used in between. Also 
glLineWidth() will only accept 1.0.

Most drivers will probably support old code for a while, but it might be an 
idea to move towards the cleaner API some day. I have very little idea about 
when this might become relevant. (Please tell me if you do.)

It would require quite a bit of work. Some stuff that was very simple before, 
would now require implementing a shader. Ah right, shaders ... these do not 
work pre 2.0. So in order to keep visvis running on older system, the old 
opengl API should be kept to fall back on. Doing this is a nice way that is 
easy to maintain is difficult to say the least...

Any comments, tips and thoughts are very welcome.

Original issue reported on code.google.com by almar.klein@gmail.com on 5 Jul 2011 at 2:11

GoogleCodeExporter commented 9 years ago

Original comment by almar.klein@gmail.com on 10 May 2012 at 10:08

GoogleCodeExporter commented 9 years ago
Probably not a problem for the foreseeable future.

Original comment by almar.klein@gmail.com on 20 Jun 2012 at 1:02

GoogleCodeExporter commented 9 years ago
From the pyopengl documentation 
(http://pyopengl.sourceforge.net/documentation/deprecations.html):

".. most vendors have committed to providing legacy-compatible drivers for all 
of their products ..."

Original comment by almar.klein@gmail.com on 27 Aug 2012 at 10:28

GoogleCodeExporter commented 9 years ago
Nicolas Rougier has some nice examples for drawing anti-aliased lines and such 
on a googlecode page: code.google.com/p/gl-agg/ It would be nice to have a look 
at that.

However, Visvis has en emphasis to support visualization on old machines (e.g. 
winXP). This means we need two versions for drawing lines (and whatever else we 
want to convert), which would mean an extra maintaining burden. 

For this reason, and because it does not seem to be a problem at this point, we 
will probably use the old opengl API where possible for the foreseeable future.

Original comment by almar.klein@gmail.com on 27 Aug 2012 at 10:36

GoogleCodeExporter commented 9 years ago
Another ref provided by Nicolas that might be interesting: 
http://cgg-journal.com/2008-2/06/index.html

Original comment by almar.klein@gmail.com on 27 Aug 2012 at 12:16