Re: Request for packaging: glMLite
Le mercredi 2 juin 2010 23:16:41, vous avez écrit :
> Florent Monnier a écrit :
> > This is a request for packaging the OpenGL bindings glMLite:
> > http://www.linux-nantes.org/%7Efmonnier/OCaml/GL/
> > [...]
> My first question would be: how does glMLite compares to lablGL?
Here are some points on which glMLite differs
from the institutional opengl binging:
- glMLite uses the original function names,
and the original parameter names.
- glMLite uses big-arrays for buffers and textures.
- glMLite is up to date, and does not only covers
a subset of OpenGL 1.2 (a 10 years old version)
- glMLite supports VBO which is the fastest
method to draw the primitives.
- With glMLite it is fully possible now to do
forward-compatible opengl programming.
The three last points are maybe (or maybe not) just temporary,
while no-one knows what the future is made of.
> Have you ever considered working with
> lablGL upstream on improving the existing bindings?
First please read this answer from 2007:
http://caml.inria.fr/pub/ml-archives/caml-
list/2007/12/8b33f162dd2560ea41982b814f1a32f3.en.html
or as minilink:
http://minilink.org/caml.inria.fr/1c8a.html
This was the first reason why I started my own
binding instead of using the existing one.
Now whether I have contributed to the institutional
opengl binging don't change the fact that there
are differences that are a question of taste.
I prefer to use the original opengl function
names, while I do some opengl both in ocaml
and in C. Also when reading docs and forums
it is easier if we use the original function
names.
I prefer to use big-arrays because BAs are
well integrated with ocaml and using BAs
makes interactions / dependencies with other
libs a lot more simple.
If I have these preferences, maybe other
people would have the same. So even if
the original institutional binding and
glMLite was technically equivalent, there
would still be these questions of taste.
Finally to answer your question, yes I have
contributed yet to the institutional binding,
and will maybe continue in the future,
but I won't stop devel glMLite in favor of
becoming a contributor to the institutional
binding due to the given set of preferences
which is a non-exhaustive list.
Also this is not a competition, I am fond of
ocaml and opengl and my primary goal is to
share this passion with others whichever
opengl binding they may use.
By the way I am interested in improving both
the binding that I use and the others.
> > This package is mostly written by me under GPL, except the file
> > "loader-libpng.c" written by David HENRY under MIT license.
>
> I see that there is also an embedded copy of xmlm, by Daniel Bünzli
> (under BSD 3 clause). Moreover, there several other copyright holders in
> TEST/* (under GPL). But the most worrying are files in RedBook-Samples/*
The embedded copy of xmlm is only used for generating code.
There are no pieces of it in the final result.
> I haven't investigated this much, but it doesn't look like DFSG
> compliant. But I guess these files could just be removed from the
> (source) Debian package.
The red-book is one of the main references to learn OpenGL.
The question of if the license of its samples is acceptable
for debian has probably been resolved yet.
There are probably nehe and redbook samples in the
OpenGL bindings of other programming languages,
and there are probably Debian packagers for those.
Maybe you could contact those persons to get some informations.
> In doubt, the safest bet is to get rid of
> those files in the (source) package.
If you do so, please add a README file to tell your users
that they can find those examples in the source tarball.
===================
Finally a question which is maybe more interesting:
what about glMLite and forward-compatible OpenGL programming?
It seems that you don't know OpenGL, so I probably need
to introduce this subject first.
OpenGL 3.0 specs came in 2008 but it's only a handled question now
because OpenGL 3.2 graphics cards only came out recently
since making cards and drivers requires time.
The main change is the deprecation model introduced.
In the specifications it is explained as:
"OpenGL 3.0 introduces a deprecation model in which certain features
may be marked as deprecated. Deprecated features are expected
to be completely removed from a future version of OpenGL."
In a more concrete way ATI say that they won't remove the deprecated
features soon, but in the same time they say that you should not
use those features anymore.
The specs says the same, you should not use deprecated features
anymore.
Now anyone can choose to do so or not, but in case
you wish to do so glMLite provides all you need for this purpose.
Reading specs is most of the time not a cup of tea,
so glMLite provides in its ocamldoc generated doc
the informations about which functions and parameters
are deprecated next to the interface of each.
OpenGL version 3.X / 4.X provides a new header file
that you can get from:
http://www.opengl.org/registry/api/gl3.h
and that you should install in:
/usr/include/GL3/gl3.h
and include through:
#define GL3_PROTOTYPES 1
#include <GL3/gl3.h>
It is still possible to compile glMLite with the old
header file, and it is possible to compile glMLite
with the new header too.
If you want to compile glMLite with the new headers, just use:
% make <target> USE_GL3_CORE_PROFILE=OK
compiled like this, calling any deprecated function will raise an exception,
and using a deprecated parameter with a non-deprecated
function will also raise an exception.
Also please consider that you can select the
forward-compatible model even if you are using
an OpenGL version 2.1.
You can even compile with <GL3/gl3.h> and the
glMLite flag USE_GL3_CORE_PROFILE=OK if are
using OpenGL 2.1.
I have also written a tutorial about writing forward-compatible
ocaml-opengl programs that may help beginners and
people used to the old model:
http://www.linux-nantes.org/~fmonnier/ocaml/GL/ocaml-opengl-howto-fc.php
Maybe you could be interested about how this has been handled in Python:
http://pyopengl.sourceforge.net/documentation/deprecations.html
http://us.pycon.org/2009/conference/schedule/event/94/
I hope all these answers will help you in taking your decision
about if you will package glMLite into Debian or not.
--
Best regards,
Florent
Reply to: