Port freetype-gl examples from GLUT to glfw

[adrianbroher]

For some reason I'm unable to append new commits to PR #54, so I open a new PR.

[rougier]

Thanks for the hard work. I just added libglfw3-dev in .travis.yml in order to test it.

Can you rebase ?

[adrianbroher]

Thanks for the hard work. I just added libglfw3-dev in .travis.yml in order to test it.

That won't work.

Travis uses an old Ubuntu version which doesn't provide any glfw3 package. You should better revert the commit on master as it breaks the Travis build.

[rougier]

Yes, and also I did not see you already changed the travis file. Sorry for the mess.

[adrianbroher]

I think there is a bug or 'not quite correct use of cmake install' in the glfw3 build system. I will update the PR when I have investigated this some more.

[rougier]

Ok. I get this from cmake:

CMake Error at CMakeLists.txt:78 (FIND_PACKAGE):
  By not providing "Findglfw3.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "glfw3", but
  CMake did not find one.

  Could not find a package configuration file provided by "glfw3" with any of
  the following names:

    glfw3Config.cmake
    glfw3-config.cmake

  Add the installation prefix of "glfw3" to CMAKE_PREFIX_PATH or set
  "glfw3_DIR" to a directory containing one of the above files.  If "glfw3"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!

[adrianbroher]

Ok. I get this from cmake:

This is related to an already known issue in glfw (glfw/glfw#483 and glfw/glfw#460).

The workaround is to move the cmake config files in the right place and set the right search pathes for includes and libraries. See also:

https://github.com/adrianbroher/freetype-gl/blob/6880bea9dc90e867874ac968c8551dd5f67ad1cb/.travis.yml#L38

[adrianbroher]

Sorry, the PR is still somewhat messy and probably will stay messy until I can fix the travis issues.

[adrianbroher]

Pull request is ready for review.

[rougier]

On OSX, I still get the glfw3Config.cmake not found error (see above).

To fix on OSX:

ln -s /usr/local/cmake/glfw ln -s /usr/local/cmake/glfw3

Maybe it's worth adding some words about linux/osx fix in the README, no ?

[rougier]

Ok, good for me. I have some resolution problems because glfw handles "retina" screen by considering separately window size from framebuffer size. The solution is to use glfwSetFramebufferSizeCallback(window, framebuffer_size_callback) instead of glfwSetWindowSizeCallback(window, window_size_callback)

[adrianbroher]

Maybe it's worth adding some words about linux/osx fix in the README, no ?

Yes, we should add a note about this bug. And I assume you meant

ln -s /usr/local/cmake/glfw /usr/local/cmake/glfw3

instead of

ln -s /usr/local/cmake/glfw ln -s /usr/local/cmake/glfw3

Ok, good for me. I have some resolution problems because glfw handles "retina" screen by considering separately window size from framebuffer size.

According to grep there is no glfwSetWindowSizeCallback call in any demo, only glfwSetFramebufferSizeCallback. Would you be so kind to post an example issue of the mentioned resolution problems?

[rougier]

You're right. This is the initial glfwSetWindowSize that is "wrong" because of OSX.
I'll try to search for a solution.

In the meantime, I think we can merge.

[rougier]

Here is the fix, can you test it in one demo to check it is working on your side ?

    int window_width, window_height;
    int framebuffer_width, framebuffer_height;

    ...

    glfwShowWindow( window );

    /* Retina screen fix (OSX) */
    glfwGetWindowSize( window, &window_width, &window_height);
    glfwGetFramebufferSize( window, &framebuffer_width, &framebuffer_height);
    if( window_width != framebuffer_width)
    {
        glfwSetWindowSize( window,
                           512 * window_width  / framebuffer_width,
                           512 * window_height / framebuffer_height);
    }

[adrianbroher]

I don't know if this is right way to fix this. Where does the 512 come from? Also it's not entirely clear to me what is the actual problem on the retina displays. Are the created windows too small?

[rougier]

512 comes from the initial window size (512x512 in texture.c) and the initial window on OSX/retina is too big (1024x1204 instead of 512x512). We've already encountered the problem in vispy: vispy/vispy#99

[adrianbroher]

I don't quite understand why the demos must be pixel exact in size. Isn't the whole purpose of the retina displays to provide a higher resolution display image regardless of the screen coordinates?

Here is the fix, can you test it in one demo to check it is working on your side ?

It doesn't work reliable. Sometime the texture demo starts properly, sometimes it's throws an X11 window error about a bad configuration, that's because the framebuffer size is not fetched properly. For some reason it returns the initial size of 1, sometimes it returns the resized size of 512 pixels, regardless if I call glfwPollEvents or not. Maybe it's a bug in GLFW or some wrong usage of the API, I don't know yet.

[rougier]

Ok, I'll investigate. In the meantime, we can merge this PR.

[codecat]

Is it necessary to link the library itself with glfw3? Why not just link all the examples with glfw3 instead?