bino-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bino-list] libgls usage + OpenGL version


From: Martin Lambers
Subject: Re: [Bino-list] libgls usage + OpenGL version
Date: Fri, 13 Nov 2015 09:32:40 +0100

Hi Bastien!

On Tue, 10 Nov 2015 16:24:37 +0100, Bastien Tran wrote:
> Question: it seems that libgls relies more on OpenGL 2.x versions
> rather than on OpenGL 3.x versions, is that right?

Yes. For maximum compatibility to old systems, both Bino and libgls use
OpenGL 2.x plus a few extensions. This introduces much unnecessary
complexity compared to modern OpenGL.

> If yes, it seems that the R package I use relies on OpenGL3.x. Is
> there a way to make use of libgls in that context or would I be
> better off rewriting my rgl library to accomodate OpenGL 2.x? This
> way I would know which version to focus on so.

If the R package uses a 3.x "compatibility profile", then all the old
OpenGL functionality is still available, and libgls should work. If it
uses a 3.x "core profile", then all the old deprecated functions are
not available anymore, and libgls will not work.

It might be worth to check which output methods you want your software
to support. It will most likely only be a subset of what Bino/libgls
support. In that case, it might be worth to rewrite these
speicific methods using modern OpenGL (based on the old code, but
simpler and more elegant due to modern features and dropped legacy
workarounds).

> Also I would indeed like to start with a minimal example, as a proof
> of concept (and to get sounder about these technologies in the
> process), any pointer about what I could/should aim for would be
> welcome. For instance I could try to force/hardcode the output mode
> but I am not sure if it is a good idea and if it will even make the
> code easier to navigate through. The idea would be to have at first
> as little code and files as possible so I can wrap my mind around it
> and understand what's going on.

I think that's the right approach. Get something working first, then
build on that, and once you know what's going on, redesign if necessary.

Best regards,
Martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]