[Haskell-cafe] GLUT, FLGW, FLGW-b
Tim C. Schroeder
tim at blitzcode.net
Fri Dec 13 09:01:02 UTC 2013
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:
(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.
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).
> 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.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe