Vlad Lopatin | 12 Dec 11:07 2013
Picon

GLUT, FLGW, FLGW-b

Hey guys,

I keep reading (wiki) that GLUT is a legacy package and some libraries (e.g. GLFW) are meant to replace it.  I also see that some of the GLUT functionality is based on fixed pipeline.  What is the current status of Haskell GLUT?  Is it 'to stay' or something that is going to be deprecated at some point?  Should one try replacing it with GLFW(-b) in a project, if fixed pipeline is not expected to be used?


Regards,
Vladimir.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Sven Panne | 12 Dec 12:05 2013
Picon

Re: GLUT, FLGW, FLGW-b

2013/12/12 Vlad Lopatin <madjestic13 <at> gmail.com>:
> I keep reading (wiki) that GLUT is a legacy package and some libraries (e.g.
> GLFW) are meant to replace it.  I also see that some of the GLUT
> functionality is based on fixed pipeline.  What is the current status of
> Haskell GLUT?  Is it 'to stay' or something that is going to be deprecated
> at some point?  Should one try replacing it with GLFW(-b) in a project, if
> fixed pipeline is not expected to be used?

I think this really depends on your needs: GLUT was designed as a
simple cross-platform API for OpenGL demos and tutorials, perhaps even
some programs of medium complexity. It was definitely not designed for
programs with complex GUI requirements. Of course you can build your
own GUI on top of OpenGL, but GLUT provides no help for that.

If you only need to create a few windows or use fullscreen, and if you
are happy with GLUT's simple event model, you can happily use it. If
you don't use forward-compatible OpenGL contexts, you can even use
GLUT's menus, fonts and geometric objects, because these are the parts
of GLUT which use the fixed pipeline internally IIRC.

Furthermore, I intend to continue maintaining the GLUT package, but
there is not that much left to do, because the underlying C library
(freeglut nowadays) hasn't really changed that much in the last few
years and I think the Haskell binding is feature-complete. If not:
https://github.com/haskell-opengl/GLUT/issues ;-)
Jason Dagit | 12 Dec 19:15 2013
Picon

Re: GLUT, FLGW, FLGW-b




On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne <svenpanne <at> gmail.com> wrote:
2013/12/12 Vlad Lopatin <madjestic13 <at> gmail.com>:
> I keep reading (wiki) that GLUT is a legacy package and some libraries (e.g.
> GLFW) are meant to replace it.  I also see that some of the GLUT
> functionality is based on fixed pipeline.  What is the current status of
> Haskell GLUT?  Is it 'to stay' or something that is going to be deprecated
> at some point?  Should one try replacing it with GLFW(-b) in a project, if
> fixed pipeline is not expected to be used?

I think this really depends on your needs: GLUT was designed as a
simple cross-platform API for OpenGL demos and tutorials, perhaps even
some programs of medium complexity.

I prefer GLFW-b for cross platform programs for the simple reason that on windows GLUT requires you to install a DLL and make sure it's in the path.

I prefer GLFW-b more generally because it's more modern, fully open source, and under active development. The license for GLUT is open in practice but it's not a clean open source license. I guess most people use freeglut instead.

Jason
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Vlad Lopatin | 12 Dec 22:45 2013
Picon

Re: GLUT, FLGW, FLGW-b

Thanks, Jason

What makes you prefer GLFW-b instead GLFW?


On 12 December 2013 19:15, Jason Dagit <dagitj <at> gmail.com> wrote:



On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne <svenpanne <at> gmail.com> wrote:
2013/12/12 Vlad Lopatin <madjestic13 <at> gmail.com>:
> I keep reading (wiki) that GLUT is a legacy package and some libraries (e.g.
> GLFW) are meant to replace it.  I also see that some of the GLUT
> functionality is based on fixed pipeline.  What is the current status of
> Haskell GLUT?  Is it 'to stay' or something that is going to be deprecated
> at some point?  Should one try replacing it with GLFW(-b) in a project, if
> fixed pipeline is not expected to be used?

I think this really depends on your needs: GLUT was designed as a
simple cross-platform API for OpenGL demos and tutorials, perhaps even
some programs of medium complexity.

I prefer GLFW-b for cross platform programs for the simple reason that on windows GLUT requires you to install a DLL and make sure it's in the path.

I prefer GLFW-b more generally because it's more modern, fully open source, and under active development. The license for GLUT is open in practice but it's not a clean open source license. I guess most people use freeglut instead.

Jason

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jason Dagit | 12 Dec 23:49 2013
Picon

Re: GLUT, FLGW, FLGW-b

I started using it after making the following comparison several years ago: http://blog.codersbase.com/posts/2011-03-17-picking-gui-library.html

Maybe that analysis is useful to you as well? Just so you know, it's probably out of date by now, so you might want to double check some of my claims. For example, the C library for GLFW doesn't use atexit() anymore (which is a good thing).

Getting back to your question: As I recall, it's better maintained, lighter weight, and it has better dependencies. With GLFW-b you can use either OpenGL or OpenGLRaw, whereas GLFW depends directly on OpenGL. The main drawback, for me, is that GLFW-b doesn't support fonts.

My proposed solution to that was to make a binding to the freetype2 library (you can find my binding on hackage/github). I never really finished that project. The binding should work but it's very low level. A few people have sent me example code they wrote to use it with OpenGL. It's really something I should finish :) The other cool thing about using freetype for fonts is that you can easily make it part of a rendering system that doesn't use any OS rendering libraries (eg., add font support to a ray-tracer).

Jason


On Thu, Dec 12, 2013 at 1:45 PM, Vlad Lopatin <madjestic13 <at> gmail.com> wrote:
Thanks, Jason

What makes you prefer GLFW-b instead GLFW?


On 12 December 2013 19:15, Jason Dagit <dagitj <at> gmail.com> wrote:



On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne <svenpanne <at> gmail.com> wrote:
2013/12/12 Vlad Lopatin <madjestic13 <at> gmail.com>:
> I keep reading (wiki) that GLUT is a legacy package and some libraries (e.g.
> GLFW) are meant to replace it.  I also see that some of the GLUT
> functionality is based on fixed pipeline.  What is the current status of
> Haskell GLUT?  Is it 'to stay' or something that is going to be deprecated
> at some point?  Should one try replacing it with GLFW(-b) in a project, if
> fixed pipeline is not expected to be used?

I think this really depends on your needs: GLUT was designed as a
simple cross-platform API for OpenGL demos and tutorials, perhaps even
some programs of medium complexity.

I prefer GLFW-b for cross platform programs for the simple reason that on windows GLUT requires you to install a DLL and make sure it's in the path.

I prefer GLFW-b more generally because it's more modern, fully open source, and under active development. The license for GLUT is open in practice but it's not a clean open source license. I guess most people use freeglut instead.

Jason


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Tim C. Schroeder | 13 Dec 10:01 2013
Picon

Re: GLUT, FLGW, FLGW-b

I'd agree, use GLFW-b. I'm very happy with it!

As far as the font rendering is concerned, if all you need is a basic bitmap font to get some text on the screen,
you might be able to use some code I wrote as a self-contained, drop-in replacement:

https://github.com/blitzcode/haskell-gol/blob/master/parallel-glfwb/src/Font.hs

(Looking at that code now, might want to bracket inside of withFontTexture. That code was written before
Simon Marlow's book taught me about the wonders of Haskell exception handling...)

I also wrote a Haskell FT2 binding. It's a very nice library with a decent API and few dependencies, so that
was quite doable. The problem is that FT2 is really 'just' a glyph rasterizer. All other functionality is
either rudimentary (kerning, glyph mapping) or out of the scope of the library (ligatures, glyph
substitution, OpenType text layout in general). You'll need another library on top / besides it to get
text rendering quality like in native GUI toolkits or a web browser. Obvious choices would be Pango or
HarfBuzz, but those are more complicated to write a Haskell binding for (dependencies, C++, etc.).

A 'just works' solution for platform and giant-GUI-toolkit independent, high-quality text rendering is
sorely missing from the Haskell ecosystem, as far as I can tell. Doing an FT2 binding and the OpenGL glyph
caching / texture atlas generation etc. is fine, but I'm afraid getting something like HarfBuzz/Pango up
and running exceeds my Cabal-fu, for now.

Cheers,
Tim

On Dec 12, 2013, at 11:49 PM, Jason Dagit wrote:

> I started using it after making the following comparison several years ago: http://blog.codersbase.com/posts/2011-03-17-picking-gui-library.html
> 
> Maybe that analysis is useful to you as well? Just so you know, it's probably out of date by now, so you might
want to double check some of my claims. For example, the C library for GLFW doesn't use atexit() anymore
(which is a good thing).
> 
> Getting back to your question: As I recall, it's better maintained, lighter weight, and it has better
dependencies. With GLFW-b you can use either OpenGL or OpenGLRaw, whereas GLFW depends directly on
OpenGL. The main drawback, for me, is that GLFW-b doesn't support fonts.
> 
> My proposed solution to that was to make a binding to the freetype2 library (you can find my binding on
hackage/github). I never really finished that project. The binding should work but it's very low level. A
few people have sent me example code they wrote to use it with OpenGL. It's really something I should finish
:) The other cool thing about using freetype for fonts is that you can easily make it part of a rendering
system that doesn't use any OS rendering libraries (eg., add font support to a ray-tracer).
> 
> Jason
> 
> 
> On Thu, Dec 12, 2013 at 1:45 PM, Vlad Lopatin <madjestic13 <at> gmail.com> wrote:
> Thanks, Jason
> 
> What makes you prefer GLFW-b instead GLFW?
> 
> 
> On 12 December 2013 19:15, Jason Dagit <dagitj <at> gmail.com> wrote:
> 
> 
> 
> On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne <svenpanne <at> gmail.com> wrote:
> 2013/12/12 Vlad Lopatin <madjestic13 <at> gmail.com>:
> > I keep reading (wiki) that GLUT is a legacy package and some libraries (e.g.
> > GLFW) are meant to replace it.  I also see that some of the GLUT
> > functionality is based on fixed pipeline.  What is the current status of
> > Haskell GLUT?  Is it 'to stay' or something that is going to be deprecated
> > at some point?  Should one try replacing it with GLFW(-b) in a project, if
> > fixed pipeline is not expected to be used?
> 
> I think this really depends on your needs: GLUT was designed as a
> simple cross-platform API for OpenGL demos and tutorials, perhaps even
> some programs of medium complexity.
> 
> I prefer GLFW-b for cross platform programs for the simple reason that on windows GLUT requires you to
install a DLL and make sure it's in the path.
> 
> I prefer GLFW-b more generally because it's more modern, fully open source, and under active
development. The license for GLUT is open in practice but it's not a clean open source license. I guess most
people use freeglut instead.
> 
> Jason
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Schell Scivally | 13 Dec 20:28 2013
Picon

Re: GLUT, FLGW, FLGW-b

I've also used a little bitmap font rendering for my tetris clone. It's very simple and I *think* that the process for using freetype is pretty similar:

1. Render all glyphs of the font into a texture.
2. Draw 2D shapes using the texture.



On Fri, Dec 13, 2013 at 1:01 AM, Tim C. Schroeder <tim <at> blitzcode.net> wrote:
I'd agree, use GLFW-b. I'm very happy with it!

As far as the font rendering is concerned, if all you need is a basic bitmap font to get some text on the screen, you might be able to use some code I wrote as a self-contained, drop-in replacement:

https://github.com/blitzcode/haskell-gol/blob/master/parallel-glfwb/src/Font.hs

(Looking at that code now, might want to bracket inside of withFontTexture. That code was written before Simon Marlow's book taught me about the wonders of Haskell exception handling...)

I also wrote a Haskell FT2 binding. It's a very nice library with a decent API and few dependencies, so that was quite doable. The problem is that FT2 is really 'just' a glyph rasterizer. All other functionality is either rudimentary (kerning, glyph mapping) or out of the scope of the library (ligatures, glyph substitution, OpenType text layout in general). You'll need another library on top / besides it to get text rendering quality like in native GUI toolkits or a web browser. Obvious choices would be Pango or HarfBuzz, but those are more complicated to write a Haskell binding for (dependencies, C++, etc.).

A 'just works' solution for platform and giant-GUI-toolkit independent, high-quality text rendering is sorely missing from the Haskell ecosystem, as far as I can tell. Doing an FT2 binding and the OpenGL glyph caching / texture atlas generation etc. is fine, but I'm afraid getting something like HarfBuzz/Pango up and running exceeds my Cabal-fu, for now.

Cheers,
Tim

On Dec 12, 2013, at 11:49 PM, Jason Dagit wrote:

> I started using it after making the following comparison several years ago: http://blog.codersbase.com/posts/2011-03-17-picking-gui-library.html
>
> Maybe that analysis is useful to you as well? Just so you know, it's probably out of date by now, so you might want to double check some of my claims. For example, the C library for GLFW doesn't use atexit() anymore (which is a good thing).
>
> Getting back to your question: As I recall, it's better maintained, lighter weight, and it has better dependencies. With GLFW-b you can use either OpenGL or OpenGLRaw, whereas GLFW depends directly on OpenGL. The main drawback, for me, is that GLFW-b doesn't support fonts.
>
> My proposed solution to that was to make a binding to the freetype2 library (you can find my binding on hackage/github). I never really finished that project. The binding should work but it's very low level. A few people have sent me example code they wrote to use it with OpenGL. It's really something I should finish :) The other cool thing about using freetype for fonts is that you can easily make it part of a rendering system that doesn't use any OS rendering libraries (eg., add font support to a ray-tracer).
>
> Jason
>
>
> On Thu, Dec 12, 2013 at 1:45 PM, Vlad Lopatin <madjestic13 <at> gmail.com> wrote:
> Thanks, Jason
>
> What makes you prefer GLFW-b instead GLFW?
>
>
> On 12 December 2013 19:15, Jason Dagit <dagitj <at> gmail.com> wrote:
>
>
>
> On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne <svenpanne <at> gmail.com> wrote:
> 2013/12/12 Vlad Lopatin <madjestic13 <at> gmail.com>:
> > I keep reading (wiki) that GLUT is a legacy package and some libraries (e.g.
> > GLFW) are meant to replace it.  I also see that some of the GLUT
> > functionality is based on fixed pipeline.  What is the current status of
> > Haskell GLUT?  Is it 'to stay' or something that is going to be deprecated
> > at some point?  Should one try replacing it with GLFW(-b) in a project, if
> > fixed pipeline is not expected to be used?
>
> I think this really depends on your needs: GLUT was designed as a
> simple cross-platform API for OpenGL demos and tutorials, perhaps even
> some programs of medium complexity.
>
> I prefer GLFW-b for cross platform programs for the simple reason that on windows GLUT requires you to install a DLL and make sure it's in the path.
>
> I prefer GLFW-b more generally because it's more modern, fully open source, and under active development. The license for GLUT is open in practice but it's not a clean open source license. I guess most people use freeglut instead.
>
> Jason
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Schell Scivally
http://blog.efnx.com
http://github.com/schell
http://twitter.com/schellsan
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Vlad Lopatin | 13 Dec 22:13 2013
Picon

Re: GLUT, FLGW, FLGW-b

>> With GLFW-b you can use either OpenGL or OpenGLRaw, whereas GLFW depends >> directly on OpenGL
Excuse me, Jason, I do not understand you here.  What are you trying to say here?

Regards, 
Vladimir


On 12 December 2013 23:49, Jason Dagit <dagitj <at> gmail.com> wrote:
I started using it after making the following comparison several years ago: http://blog.codersbase.com/posts/2011-03-17-picking-gui-library.html

Maybe that analysis is useful to you as well? Just so you know, it's probably out of date by now, so you might want to double check some of my claims. For example, the C library for GLFW doesn't use atexit() anymore (which is a good thing).

Getting back to your question: As I recall, it's better maintained, lighter weight, and it has better dependencies. With GLFW-b you can use either OpenGL or OpenGLRaw, whereas GLFW depends directly on OpenGL. The main drawback, for me, is that GLFW-b doesn't support fonts.

My proposed solution to that was to make a binding to the freetype2 library (you can find my binding on hackage/github). I never really finished that project. The binding should work but it's very low level. A few people have sent me example code they wrote to use it with OpenGL. It's really something I should finish :) The other cool thing about using freetype for fonts is that you can easily make it part of a rendering system that doesn't use any OS rendering libraries (eg., add font support to a ray-tracer).

Jason


On Thu, Dec 12, 2013 at 1:45 PM, Vlad Lopatin <madjestic13 <at> gmail.com> wrote:
Thanks, Jason

What makes you prefer GLFW-b instead GLFW?


On 12 December 2013 19:15, Jason Dagit <dagitj <at> gmail.com> wrote:



On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne <svenpanne <at> gmail.com> wrote:
2013/12/12 Vlad Lopatin <madjestic13 <at> gmail.com>:
> I keep reading (wiki) that GLUT is a legacy package and some libraries (e.g.
> GLFW) are meant to replace it.  I also see that some of the GLUT
> functionality is based on fixed pipeline.  What is the current status of
> Haskell GLUT?  Is it 'to stay' or something that is going to be deprecated
> at some point?  Should one try replacing it with GLFW(-b) in a project, if
> fixed pipeline is not expected to be used?

I think this really depends on your needs: GLUT was designed as a
simple cross-platform API for OpenGL demos and tutorials, perhaps even
some programs of medium complexity.

I prefer GLFW-b for cross platform programs for the simple reason that on windows GLUT requires you to install a DLL and make sure it's in the path.

I prefer GLFW-b more generally because it's more modern, fully open source, and under active development. The license for GLUT is open in practice but it's not a clean open source license. I guess most people use freeglut instead.

Jason



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jason Dagit | 13 Dec 22:26 2013
Picon

Re: GLUT, FLGW, FLGW-b

The GLFW-b package only depends on base and bindings-GLFW.

The GLFW package depends on base and the OpenGL Haskell package.

I often use the Haskell OpenGLRaw package instead of OpenGL. Mostly because OpenGLRaw matches the C API for OpenGL. That's nice when you're following documentation as it's almost always for the C API. So then I save myself the step of translating from C OpenGL to the Haskell OpenGL package conventions.

I could probably still use OpenGLRaw with GLFW, but it's an unnecessary dependency. I also know that GLFW-b installs cleanly just using cabal on Windows, OSX, and Linux. I don't recall if GLFW has that property. I think it might require you to install the C GLFW library separately.

I hope that helps,
Jason


On Fri, Dec 13, 2013 at 1:13 PM, Vlad Lopatin <madjestic13 <at> gmail.com> wrote:
>> With GLFW-b you can use either OpenGL or OpenGLRaw, whereas GLFW depends >> directly on OpenGL
Excuse me, Jason, I do not understand you here.  What are you trying to say here?

Regards, 
Vladimir


On 12 December 2013 23:49, Jason Dagit <dagitj <at> gmail.com> wrote:
I started using it after making the following comparison several years ago: http://blog.codersbase.com/posts/2011-03-17-picking-gui-library.html

Maybe that analysis is useful to you as well? Just so you know, it's probably out of date by now, so you might want to double check some of my claims. For example, the C library for GLFW doesn't use atexit() anymore (which is a good thing).

Getting back to your question: As I recall, it's better maintained, lighter weight, and it has better dependencies. With GLFW-b you can use either OpenGL or OpenGLRaw, whereas GLFW depends directly on OpenGL. The main drawback, for me, is that GLFW-b doesn't support fonts.

My proposed solution to that was to make a binding to the freetype2 library (you can find my binding on hackage/github). I never really finished that project. The binding should work but it's very low level. A few people have sent me example code they wrote to use it with OpenGL. It's really something I should finish :) The other cool thing about using freetype for fonts is that you can easily make it part of a rendering system that doesn't use any OS rendering libraries (eg., add font support to a ray-tracer).

Jason


On Thu, Dec 12, 2013 at 1:45 PM, Vlad Lopatin <madjestic13 <at> gmail.com> wrote:
Thanks, Jason

What makes you prefer GLFW-b instead GLFW?


On 12 December 2013 19:15, Jason Dagit <dagitj <at> gmail.com> wrote:



On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne <svenpanne <at> gmail.com> wrote:
2013/12/12 Vlad Lopatin <madjestic13 <at> gmail.com>:
> I keep reading (wiki) that GLUT is a legacy package and some libraries (e.g.
> GLFW) are meant to replace it.  I also see that some of the GLUT
> functionality is based on fixed pipeline.  What is the current status of
> Haskell GLUT?  Is it 'to stay' or something that is going to be deprecated
> at some point?  Should one try replacing it with GLFW(-b) in a project, if
> fixed pipeline is not expected to be used?

I think this really depends on your needs: GLUT was designed as a
simple cross-platform API for OpenGL demos and tutorials, perhaps even
some programs of medium complexity.

I prefer GLFW-b for cross platform programs for the simple reason that on windows GLUT requires you to install a DLL and make sure it's in the path.

I prefer GLFW-b more generally because it's more modern, fully open source, and under active development. The license for GLUT is open in practice but it's not a clean open source license. I guess most people use freeglut instead.

Jason




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane