Re: GLUT, FLGW, FLGW-b
Tim C. Schroeder <tim <at> blitzcode.net>
2013-12-13 09:01:02 GMT
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