On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne wrote:

2013/12/12 Vlad Lopatin :

...

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

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 wrote:

Thanks, Jason

What makes you prefer GLFW-b instead GLFW?

On 12 December 2013 19:15, Jason Dagit wrote:

...

On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne wrote:

...

...

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

2013/12/12 Vlad Lopatin : 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

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. https://github.com/schell/blocks/blob/master/src/Graphics/TextRenderer.hs#L9... On Fri, Dec 13, 2013 at 1:01 AM, Tim C. Schroeder 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...

(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 wrote: Thanks, Jason

What makes you prefer GLFW-b instead GLFW?

On 12 December 2013 19:15, Jason Dagit wrote:

...

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

On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne wrote: 2013/12/12 Vlad Lopatin : 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

-- Schell Scivally http://blog.efnx.com http://github.com/schell http://twitter.com/schellsan

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 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 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 wrote:

...

Thanks, Jason

What makes you prefer GLFW-b instead GLFW?

On 12 December 2013 19:15, Jason Dagit wrote:

...

On Thu, Dec 12, 2013 at 3:05 AM, Sven Panne wrote:

...

...

I keep reading (wiki) that GLUT is a legacy package and some

...

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

2013/12/12 Vlad Lopatin : libraries (e.g. 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