Multiwindow using glfw #1470

wants to merge 94 commits into


None yet

This branch uses glfw as the window system and ditches glut. But ofAppGlutWindow can still be used by modifying main.cpp

to use glfw:

ofSetupOpenGL(ofGetWindowManager(), 640,480, OF_WINDOW);    

to use glut:

ofAppGlutWindow window;
ofSetupOpenGL(&window, 1024,768, OF_WINDOW);

I was using this branch for the last couple of weeks on ubuntu and think it is pretty stable. But it needs compiled libs for mac & windows. The glfw version I use is a fork of the official glfw repo

We should not merge this before those compiled libs are in there.

I send this pull request mainly to have a place to get a discussion going. It'd be great if someone could try this and test if it works for them too :)

Philip Whitf... added some commits Mar 8, 2012
Philip Whitfield working on cocoa 4ab17b3
Philip Whitfield cleaning up 56709c0
Philip Whitfield added empty multiwindow example 0c9989b
Philip Whitfield basic window opens on OS X 1c4ff8c
Philip Whitfield added opengl context on OS X 6dbf3d7
Philip Whitfield added files for X11 882c8a8
Philip Whitfield added basic listeners 42517ac
Philip Whitfield cleaning up x11 code e9f255c
Philip Whitfield X11 window is drawing opengl. yeeha 7369995
Philip Whitfield creating multiple windows on X11 kind of works 80bdcde
Philip Whitfield opengl drawing on OS X 9a8c34e
Philip Whitfield mapping ofGetWidth and ofGetHeight to correct window e061e1b
Philip Whitfield resize / move events handling on OS X e77c721
Philip Whitfield setWindowShape & setWindowPosition on OS X 9503ed3
Philip Whitfield non blocking events on OS X f27350c
Philip Whitfield basic glfw integration, example works e83ba7a
Philip Whitfield added ofWindowToOfBaseApp 0d8a467
Philip Whitfield performance optimizations and multiple windows finally works 1e49d40
Philip Whitfield proper window delete 4c18d25
Philip Whitfield refactoring and extended example 621e5e0
Philip Whitfield added linux64 glfw libs ea8210e
Philip Whitfield bugfix: changed setWindowShape(w,w) to setWindowShape(w,h) 7085c8a
Philip Whitfield updated code::blocks project, bugfix with setWindowShape 7356693
Philip Whitfield Merge branch 'multiwindow' of int…
…o multiwindow

Philip Whitfield added mouse move event 8acc39b
Philip Whitfield Merge remote branch 'upstream/develop' into multiwindow f88ef12
Philip Whitfield added include for <map> a11286a
Philip Whitfield added mosueMoved and Dragged functions 415bbe4
Philip Whitfield Merge remote-tracking branch 'upstream/develop' into multiwindow 8b2b92f
Philip Whitfield added scrolling events 70f8c60
Philip Whitfield Merge branch 'multiwindow' of int…
…o multiwindow
Philip Whitfield added key events eb224df
Philip Whitfield added bool ofWindow::isKeyPressed() a9dca75
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow
Philip Whitfield added ofWindow::setWidth & setHeight e8262fc
Philip Whitfield added ofWindow:: get/set X & Y ea96949
Philip Whitfield added windowMove events 07d70b2
Philip Whitfield updated glfw lib for os x 91a9e25
Philip Whitfield updated glfw header file 203386f
Philip Whitfield added ofWindow::close() bdbb818
Philip Whitfield modified ofEventArgs to support ofWindow, switched to event driven li…
Philip Whitfield merge with upstream/develop 5a2d127
Philip Whitfield added close event to window and bool window::isClosed() 4cb5308
Philip Whitfield modified makefile.linux to include system lib Xrandr 1f8595e
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow

Philip Whitfield Merge branch 'develop' of in…
…to multiwindow
Philip Whitfield updated linux glfw libs 4094c4b
Philip Whitfield added getFrameRate method 321789c
Philip Whitfield updated example 94eec9c
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow
Philip Whitfield updated the glfw libs for linux64 8d489ab
arturoc commented Aug 8, 2012

this is great! i recently saw that they are working in an egl version of glfw so it should work in the raspberry pi and similar which makes it even a better choice for OF.

have you done any modifications to glfw? i'm looking through your repo but can't see any.

will test it soon


No, I did not yet change anything in glfw. The separate repo is only a precaution and to make sure we use the same version on all platforms.

So far my only concern was to make the integration work. And because they are still heavily working on glfw, I don't think it would make much sense to change something right now.

[EDIT] But I am very tempted to add drag'n'drop support to glfw...

arturoc commented Aug 8, 2012

perfect, i was just asking to know if you needed to modify anything to get multiwindow working.

also from what i've seen the development of glfw is happening now mostly on github and there's several people involved through PR's and several branches so i think it would be relatively easy to get additions/modifications accepted if we need them

Philip Whitfield partial cleanup f7a3372

could you let the uncrustify formatter (scripts/dev/style/) run over the OF-related files? from a cursory inspection, it could use a run to make it conform to the OF code style.


@bilderbuchi Didn't know that script existed. Should be fixed now...


great, thanks :-)


I'm having some problems with ofDrawBitmapString. Sometimes it works and sometimes I only get white bars and no font (on ubuntu). Bitmap string works with images, right? Maybe those images are initialized too early or not at all. is there some command that gets called to create them or how does it work?

arturoc commented Aug 9, 2012

it actually uses a texture but it's lazily initialized the first time it's used so it shouldn't be a problem. perhaps try to wait some frames before drawing the text to see if that fixes it but don't think it's the reason. the code is in ofBitmapFont

ofTheo commented Aug 25, 2012

does this still need os x and win libs ?
or what is left to be able to merge this in?


It still needs win libs. Mac & Linux are ready.

EDIT: actually linux 32bits libs are missing too. Will add them later today.


We could also use a neat example. Anybody got a good idea?

Philip Whitf... and others added some commits Aug 27, 2012
Philip Whitfield little cleanup, removed unnecessary file in projectgenerator/bin b9d41cf
Philip Whitfield Merge branch 'multiwindow' of int…
…o multiwindow
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow


This probably broke the XCode project. Could somebody test and
eventually fix this?
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow

This may have broken the XCode project

bakercp commented Oct 16, 2012

Hi Friends, I'm attempting to get GLFW running on Raspberry pi to work with this branch, but still running into issues, even with the GLFW EGL branch. Has anyone tried this?

Philip Whitf... added some commits Oct 17, 2012
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow

Philip Whitfield Merge branch 'multiwindow' of int…
…o multiwindow


@bakercp would be awesome if this worked. I'm sorry that I can't help you but I have no raspberry...

ofZach commented Oct 17, 2012

I have rasberry pi I can loan out for a couple of weeks if it helps. email me off github...

(sorry didn't mean to close the pull request, reopening)

@ofZach ofZach closed this Oct 17, 2012
@ofZach ofZach reopened this Oct 17, 2012

mail sent

bakercp commented Oct 17, 2012

Also, I started a branch last night here

I've updated all of the linux makefile/.sh scripts and now have oF release and debug libs compiled, and all of the other libs (except fmodex compiled). Nothing "working" yet, but the foundation is being built.


@bakercp I now have a raspberry pi. Do you mind answering some questions about your branch on IRC or something?

bakercp commented Oct 24, 2012

hey @underdoeg -- most certainly. I'll contact you offline via email.

underdoeg and others added some commits Oct 29, 2012
underdoeg updated xcode project files 739ca74
underdoeg added example for xcode to /examples/other/multiwindowExample 0e060ca
Philip Whitfield fixed shared context 2254ce5
Philip Whitfield Merge branch 'multiwindow' of int…
…o multiwindow
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow
Philip Whitfield updated glfw
NOTE: this will break mac projects until the newest lib is recompiled
Philip Whitfield added win_cb libs fa9a0f3

I finally added the compiled glfw libs for Code::Blocks on windows. But I can't create the visual studio projects with cmake. It fails with the following error:

LINK : fatal error LNK1123: Fehler bei der Konvertierung in COFF: Datei ist
ungültig oder beschädigt.

Don't know why it is German but it means something like

LINK : fatal error LNK1123: Error converting COFF: File is invalid or corrupted

bakercp commented Dec 18, 2012

Hey @underdoeg would you be able to update this to work with the recent ofEvents updates (and a few others)? I'm ready to do some heavy testing on this branch and would make the updates myself ... but figured that you might be able to do it more quickly. Cheers, CB

Philip Whitf... added some commits Dec 28, 2012
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow

Philip Whitfield Merge branch 'multiwindow' of int…
…o multiwindow


@bakercp done. sorry for the delay...

bakercp commented Dec 28, 2012

Exciting -- checking it out. Thanks!


@bakercp great! What plattform are you trying? Mac? I wonder if OF_GAME_MODE works as expected. I'm currently developing on ubuntu. Next task is fullscreen toggling...


@bakercp btw, I just updated the glfw libs from the current github master and cmake now has a new built in option GLFW_USE_EGL to enable. Don't know if it already works on the raspberry and similar devices though...

Philip Whitf... added some commits Dec 28, 2012
Philip Whitfield updated glfw libs
WARNING! windows code::blocks lib is currently still outdated
Philip Whitfield fixed wrong swap interval 6e43760
Philip Whitfield added fullscreen funcitonality for linux 8fec0f4
yty commented Dec 29, 2012

glfw can support NOTIFYICONDATA callbackMessage?

maybe,glut can't do it.

void ofAppGlutWindow::initializeWindow(){

glutCustomFunc();   --------------->> glut  is not there . glfw Is there?


For example


 tnd.uCallbackMessage=WM_MYMESSAGE; ------------------------>> my custom Message....
 strcpy(tnd.szTip,"test tray");


@yty You mean if you're able to use thisNOTIFYICONDATA functionality with glfw? I guess so. It's probably not built in but glfw can expose the native window handlers and I guess that is all you need for native system calls?

bakercp commented Jan 3, 2013

Hey @underdoeg I''ve spent some time with this and have a few initial thoughts:

  • Is there a way to move away from the * pointer style for ofWindow? It seems to mix both raw and ofPtr (via ofWindowPtr). It seems that all of them could be replaced with ofWindowPtr. The only hangup I found is when the window itself calls the window manager to activate the current window using the this argument. That could be fixed via a friend class setup. Another option would be to get rid of the default constructor on ofWindow and use something like ofWindowPtr getInstance() to keep it all raw-pointer free. Maybe it's not a big deal, but it seems that we need to do one or the other and not mix. Then in the destructor for ofWindow we just need to make sure that the window manager and glfw both are notified and everything is destroyed in the correct order ... (perhaps not trivial :)).
  • I'm wondering if our ofEvents need to have a base field with a window id (ideally just an unsigned int)? I'm imagining that you could add this (referring to the main testApp class as a listener to the main window, if the main window class implemented / extended the listener). In such a case, it would be important to know where various events were coming from.
  • With GLFW, we can get rid of the bug-prone #652 pressedKeys , although with GLFW it might stay updated a little better ... or maybe not. Is there an easy way that we could bypass that functionality when using the glfw window? It seems like you might just look at the current window and see if it is glfw.
  • Fullscreen - it looks like this is still not implemented on os x and will need to be custom platform-specific code, unless we destroy and create the new windows each time the windowMode is changed? Any idea why glfw doesn't implement this internally? It seems like a pretty basic thing ... ?

More thoughts over the next few days.

Overall, this is a very exciting (and much needed) departure from GLUT. Even if it didn't offer multiple windows it would be an upgrade!


Hey @bakercp Cool you had the time to check it out. I'll just post my initial thoughts right now:

  • Sure we could use an ofWindowPtr somehow. (I'm not going into all the technical problems now.) What is your main reason for this? Cosmetics or functionality? I'm asking because if I as a user request a window pointer, I'll assume that all destruction etc will be handled internally. Or are you rather concerned that a user might accidentally keep an ofWindow* that actually points to a destroyed window?
  • I have created a base class ofWindowEvent for that purpose that has a pointer to the ofWindow that is sending the event. This touches the ofWindowPtr thing but I think it might be more convenient than just an id?
  • AFAIK glfw also does not have this handled right. But I think with custom window code and glfwGetKey() to check whether a modifier key is pressed, we might be able to get somewhere? (Have you ever tried this. It's also not flawless but is the right direction )
  • I have no idea why this isn't implemented. It also wasn't in the older version. I think the idea is to either use game mode or windowed mode... (?) But it is fairly easy to build in, so I'm not that concerned about it. I'll try the mac version when I get to a mac again. (my mac vm somehow broke...)
bakercp commented Jan 5, 2013

I've continued to spend more time on this today and have a few discussion questions / propositions, particularly related to input events.

  1. the mouseDragged event has traditionally reported both the drag position AND the (supposed) button that is being pressed to cause the "move" to become a "drag". But, in the current paradigm, that single number does not completely describe the situation of multiple buttons being pressed, or pressed and released in succession. Instead, if you really want to know which buttons are being pressed, you must call ofGetMousePressed() with an optional argument to query a specific button. GLFW (like many windowing systems) does not report "drag" events, but rather reports mouse movement and lets the user check to see if any mouse button is pressed. Thus, instead of making documentation caveats about what the "button" in the drag function actually means, I'd propose removing the "button" argument from the drag function and encouraging the use of ofGetMousePressed() to discover the true nature of the buttons being pressed.
  2. Unified touch / mouse and "pointer" events. This one may be more controversial, but I would propose that we take the opportunity to unite touch and mouse events into a single ofPointer event. Pointer is the term used by Microsoft and others to describe "pointing" input devices like touches, mice, trackballs, pens, etc. While many of the parameters like "touch size" and "pressure" would simply be set to default static values for a mouse event (for instance), it would offer more flexibility for guis, etc. Within the ofPointer there would be an enum that described the device "type" (mouse, touch, pen, etc). GLFW has plans to incorporate touch events in the 3.0 roadmap, and most modern operating systems now support touch events to varying degrees. This would also help us move toward making ios apps look a little more like desktop apps, and would also allow easy integration with addons like ofxManyMouse, TUIO, and addons that attempt to leverage the OSX multitouch private framework.
  3. I'd propose starting an official openFrameworks branch for this so that it is easy for people to start testing this very thoroughly. I'd also propose going GLUT free on that test branch rather than having both windowing systems living side by side (which I know was @underdoeg original intent).

I'm pushing a bunch of updates, additions and proposals over to @underdoeg tomorrow for discussion. @kylemcdonald perhaps we can talk about some of this in the IRC meetup tomorrow?

ofZach commented Jan 5, 2013

quickly, I'm not a huge fan of (1) since it seems sort of counter intuitive to me. It probably makes sense to look at a majority of cross platform window systems (ie, and see what they do. To be honest, I haven't seen that many mouseMoved only window systems, but maybe I haven't seen that many window systems :) curious what other people think ?

but 2 would make a lot of sense and it's something that's been discussed before . I would support very much. ofPointer is kind of an easily misleading name however, since pointer / ptr has so much c++ connotation.

Also, we sort of already have this with the touch event in ofEvents:

          class ofTouchEventArgs : public ofEventArgs {
        enum Type{
        } type;

        int id;
        int time;
        float x, y;
        int numTouches;
        float width, height;
        float angle;
        float minoraxis, majoraxis;
        float pressure;
        float xspeed, yspeed;
        float xaccel, yaccel;

so it might just be a matter of finding a way to make the mouse events mesh better with the touch events.

a branch for this kind of development sounds good to me....


I also feel like 1 is a little counter intuitive. But it sure makes sense and that is why all window managers implement it in that way. But on the other hand with OF we're trying to simplify stuff (otherwise you could just use glfw directly...) I feel like it is always some sort of balancing act between simplicity and the "correct" way to do things. I like the approach to have the most common usage wrapped up as easily as possible and if you need special functionality you can get it by a little digging into the more hidden functions.

But about the dragging and mouse pressed argument in general. What if mouse pressed was some sort of specialized vector? so you'd have a syntax like

event.mouse.pressed(0) //button 0 is pressed
or that could also be event.mouse.pressed(OF_MOUSE_BUTTON_LEFT)

2 absolutely needs to be done in the near future IMO

3 With this multiwindow branch we could go two ways. a) to simply remove GLUT and replace with GLFW without touching the general syntax as much as possible. That's what I tried to do so far and in this case I don't mind having GLUT still in there as an option. or b) to rethink how input events, and other window events are handled and do it in a smarter way. But that probably leads to signficant API changes and may even result in compatibility issues with older apps.

When I started the branch, I would have loved to do b) straight away but I thought the proper way would probably be to do a) first and when glfw if properly within OF and everything works as before, we can move to b).

But I also think we should have a branch on the official OF repo.

bakercp commented Jan 9, 2013

@yty I'm not on windows, but an example of a native system call example for Cocoa is (it has to live in an .m file):

bool ofCocoaWindowSetPosition(GLFWwindow win, int x, int y) {
     id cocoaWindow = glfwGetCocoaWindow(win);
     CGSize size = CGDisplayBounds(CGMainDisplayID()).size;
    NSPoint pnt;
    pnt.x = x;
    pnt.y = size.height - y;
    [cocoaWindow setFrameTopLeftPoint:pnt];

the glfw3native.h header exposes the following for windows:

GLFWAPI HWND glfwGetWin32Window(GLFWwindow window);
GLFWAPI HGLRC glfwGetWGLContext(GLFWwindow window);

I discovered that the OSX static lib in @underdoeg's repo was not compiled with native window exposure compiled in, so I had to change some cmake settings and recompile to get it. I believe it is compiled in for Linux, as it is being used for the x11 native fullscreen work-around. If you get missing symbols for glfwGetWin32Window you'll likely need to recompile it. If you do, use @underdoeg's fork of GLFW, because some features have changed in the main GLFW branch even since he made his clone.

Also, make sure that you do something like:

// to expose native window
#ifdef TARGET_WIN32
#include "glfw3native.h"
#include <GL/glfw3native.h>
#include "ofCocoaWindowUtils.h"
#include "glfw3native.h"

in your code to both expose the native methods and include the glfw3native.h headers.


@bakercp That is correct, I have the native window exposure only compiled on linux atm. Will you include the libs for OS X with your PR? I plan on updating my glfw fork soonish. I should be able to recompile windows and linux then. Can you do mac when I'm ready? Somehow my lion vmware image doesn't boot anymore.

bakercp commented Jan 9, 2013

Yeah, I'll include the osx lib with my PR (coming soon, seriously), and yes I'm happy to compile the osx version when we update. The current main branch makes a few changes that break things like window / screen size. Z.B, I think it breaks:

ofPoint ofWindow::getScreenSize() {
    // NB: "This function will change when the glfw multi-monitor branch is merged.
    // in multi-monitory branch we can use glfwGetMonitors, glfwGetPrimaryMonitor etc.
    GLFWvidmode vidMode;
    return ofPoint(vidMode.width,vidMode.height,0);

because glfwGetDesktopMode is being replaced by the work on the multiwindow branch (which is almost integrated and may be what we should be using for our next update ...).

Philip Whitf... added some commits Mar 7, 2013
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow

NOTE: I may have broken the xcode project file




Philip Whitfield fixed linux 32 & 64
maybe some dependencies have to be added to the install_dependencies
Philip Whitfield Merge branch 'multiwindow' of int…
…o multiwindow
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow

Philip Whitfield updated glfw 4c208b1
Philip Whitfield Merge branch 'develop' of in…
…to multiwindow



I just updated to the latest glfw dev version. @bakercp do you have the time to recompile the os x libs?

arturoc commented Apr 4, 2013

@underdoeg what's the state of this? the gles2/gl3 branch is done already and i want to integrate this before merging into develop


hey @arturoc It works and could be merged. However it still needs testing by other users than me. Especially on other platforms. I currently only use linux so the compiled glfw libs are only up to date on that platform. I could work on the windows libs but I don't have an up to date os x system.

arturoc commented Apr 4, 2013

ok, no worries, i'll merge it in my branch and test in other platforms i mortly wanted to know if the api was finished


The API is finished. There might be some functions missing but all in all it is ready. But it is very much built around backwards compatibility. I was talking with bakercp about that if it would make sense to use this opportunity to clean up how things are handled in the core. Especially the app/renderer initialization. This is something this branch does not do. It tries to mimic the existing API and at points kind of hacks the multiwindow functionality into an API that is originally built for single window usage. But best will be if you try it out. You'll probably see what I am referring to...


One major issue though is c style functions that refer to window properties are handled. e.g calls like ofGetWidth(). Right now it returns the width of the currently active window but it could also always refer to the main window.

kalwalt commented Apr 4, 2013

hi @underdoeg this will works also on linuxarm ?


@kalwalt glfw 3.0 is still not officially released. But linuxarm and EGL support are part of the roadmap. Last time I tried was about half a year ago and then I didn't manage to run glfw on my raspberry. It might work now though...

kalwalt commented Apr 4, 2013

i tried glfw (i think the 3.0 now i don't remember..) time ago with my Pandaboard and it works fine. The problem is integrate in OF with linuxarm see this issue openFrameworks-RaspberryPi#148 but maybe with your multiwindow that can be solved. i will give a try.


I see... Not sure if this is solved atm.
But I've commented on your issue. Did you try that already? This might be relevant for this branch as well.

kalwalt commented Apr 5, 2013

@underdoeg i'm trying your multiwindow branch in linuxarm (Pandaboard) but i get an error in

ofGstUtils.h:12:21: fatal error: gst/gst.h: No such a file or directory

this because you start multiwindo in the develop branch but for linuxarm i need the develop-raspberrypi branch . I think that i try to open a new branch from develop-raspberrypi and add your files . i think that there are not other options. will see what happens!

kalwalt commented Apr 5, 2013

maybe can you give me a list of the files of your insertion and changes?


oh, I see. that is not as easy, I did actually change quite a lot in different files... Do you get a lot of unmerged files if you simply try to pull my branch into the raspberry branch with git?

arturoc commented Apr 5, 2013

i've just merged the multiwindow branch in my programmable renderer one which already has all the elinux changes, i'm doing some changes but will upload it in a bit

kalwalt commented Apr 5, 2013

@underdoeg i simply did a git fetch with your repo as upstream, well i can try a pull but i'm not feel very confortable with such git operations! i can give a try in the time @arturoc make his changes.

kalwalt commented Apr 5, 2013

it's not simple , I used your ofEvents.h, ofEvents.cpp, ofEventsUtils., ofWindow.h, ofWindowManager, ofBaseApp, and ofMain, i had to remove the EGL app window ( because use others ofEvent functions) but i got this error :

../../../libs/openFrameworks/window/ofWindowManager.cpp: In member function ‘ofWindow* ofWindowManager::createWindow(int, int, int, int, ofWindowMode)’:
../../../libs/openFrameworks/window/ofWindowManager.cpp:145:70: error: invalid conversion from ‘void ()(GLFWwindow, int, int)’ to ‘GLFWcursorposfun {aka void ()(GLFWwindow, double, double)}’ [-fpermissive]
../../../libs/glfw/include/GL/glfw3.h:1812:14: error: initializing argument 2 of ‘void glfwSetCursorPosCallback(GLFWwindow_, GLFWcursorposfun)’ [-fpermissive]
../../../libs/openFrameworks/window/ofWindowManager.cpp: In member function ‘void ofWindowManager::glfwChar(GLFWwindow_, int)’:
../../../libs/openFrameworks/window/ofWindowManager.cpp:534:13: warning: unused variable ‘win’ [-Wunused-variable]
../../../libs/openFrameworks/window/ofWindowManager.cpp: At global scope:
../../../libs/openFrameworks/window/ofWindowManager.cpp:102:12: warning: ‘nFramesForFPS’ defined but not used [-Wunused-variable]
make[2]: *** [../../../libs/openFrameworksCompiled/lib/linuxarmv7l/obj/Release/libs/openFrameworks/window/ofWindowManager.o] Error 1
make[1]: *** [Release] Error 2
make: *** [Release] Error 2

i added an -fpermissive in PROJECT_CFLAGS but not help at all.


ok, I see. what glfw header files are you using? the one in my branch or did you redownload them from I guess the glfw api changed a little bit and is not compatible anymore with my version. This is easy to fix on my side but since arturo is also working on this, I'll leave my branch ATM. Maybe try it with my branch of glfw which is the one I use for the multiwindow stuff. it should be compatible but is one month behind...

kalwalt commented Apr 5, 2013

i m using the elmindreda glfw3.h, instead i wil try with your glfw header but i believe that the static lib won't works. i wil to build another static lib with it. Thanks for the info.

bakercp commented Apr 5, 2013

Hey @underdoeg I have a bunch of updates to this branch that I was working on a month or so ago and it was paused due to other projects. I'm back on this shortly though and will get the recompiled static libs, into a PR against this branch.

arturoc commented Apr 5, 2013

@underdoeg i'm testing this with the programmable renderer, and there we need to use shaders for everything. right now i'm creating the shaders as static instances in ofShaders but the second window doesn't see them. I can create a renderer per window or have a shared context, or have the option for both.

is there a way of activating a shared context?

arturoc commented Apr 5, 2013

mmh, so it seems that the shaders are actually shared but the vbo's are not, if i create a different vbo in the secondary window then it works.

btw, there's lots of bugs yet, several methods from ofBaseAppWindow are not implemented, setup is not being called on the listeners, the scroll event is passed to all windows, orientation is not implemented...

the architecture is also kind of messy. i'm refactoring things a bit. @bakercp, can you upload your changes? no matter in what state they are i'm redoing lots of stuff so just to take a look or merge your changes before going any further.

arturoc commented Apr 5, 2013

it seems vaos,fbos and other objects are not shared among contexts, i've added a renderer per window and that solves the problem. i've also changed most things to use ofPtr instead of plain pointers but it think it might be better to convert windows to PIMPL so people don't need to use pointers at all

i'm working here:

arturoc commented Apr 5, 2013

btw, @kalwalt that branch already contains the elinux changes so it should work on pandaboard. let me know if it does

kalwalt commented Apr 5, 2013

wow i'm going to fetch that branch but how can i grab only that branch? i add in gitignore the url of your github address but if i do

git fetch upstream

i grab all your branch in my repo that is crazy....

arturoc commented Apr 5, 2013

yes you can just do:

git checkout develop
git checkout -b feature-elinuxglfw
git pull feature-elinuxProgrammableGLFW

arturoc commented Apr 5, 2013

oh, just realized that i recompiled glfw from the latest in github but only for linux64 so you might need to recompile it for armv7 too

kalwalt commented Apr 5, 2013

this is not a problem for me. I have problem with the git branches. because i'm in the raspberrypi branch i'havent the develop one only the develop-raspberrypi branch . i did

git checkout develop

but i haven't so i fetched from the openframeworks upstream give me a lot of conflicts.?!
so i started form the develop-raspberrypi branch but when i did

git checkout -b feature-elinuxglfwFrameworks feature-elinuxProgrammableGLFW

git said me

error: The following untracked working tree files would be overwritten by merge:

a long list of files


arturoc commented Apr 6, 2013

that's because you have modified some files and it cant pull the changes till you discard or commit those files.

you can try:

git stash

before pulling but perhaps it's easier for you to download the zip from the github page

kalwalt commented Apr 6, 2013

@arturoc i did the second option , easier and less troubles. Now, i'm going to try the branch. One question more: what version of glfw did you use to build the static lib ( i know that is the 3) but the latest from:
Thank you

arturoc commented Apr 6, 2013

yes that's it, but i just realized that i haven't committed those changes yet so it should work as it is

kalwalt commented Apr 6, 2013

ok will see what can i do.

kalwalt commented Apr 6, 2013

while compiling the OF static lib i get an error in

ofAppEGLWindow.cpp 32:29: fatal error: ofGLES2Renderer.h: No such file or directory.

looking into libs/openFrameworks/gl i can't see any ofGLES2Renderer.h maybe the class is inside another header now?

arturoc commented Apr 6, 2013

oh, forgot to change that, it should be working now

kalwalt commented Apr 6, 2013

i can't compile the code. i have this issue now: i think it's similar to this one #1984 .


cool, looks like something is happening here. sorry for my absence. I pinched a nerve or something and cant' really use my computer atm. I'll get back to this as soon as possible.

kalwalt commented Apr 7, 2013

@underdoeg @arturoc don't look at my previous post above, Because i started my branch feature-elinuxglfw from the develop-raspberrypi branch now with a fresh clone i strted from develop i get others errors see here

few points to see:
1)openssl is not recognized? i have libssl-dev
2)various EGL errors
3)ofIsVFlipped() : i can't find this...

@underdoeg take care of you!

p.s. also i want to test this in linux64

kalwalt commented Apr 7, 2013

no i'm wrong on the 1 point = i haven't installed libssl-dev. Now installed it but still remains the others two.

kalwalt commented Apr 12, 2013

now i'm testing the feature-elinuxProgrammableGLFW in Ubuntu12.04 64 bit . i have a main.cpp like this:

#include "ofMain.h"
#include "testApp.h"
//#include "ofAppGlutWindow.h"
#include "ofAppGLFWWindow.h"

int main( ){

ofAppGLFWWindow window;
ofSetupOpenGL(&window, 1024,768, OF_WINDOW);            // <-------- setup the GL context

// this kicks off the running of my app
// pass in width and height too:
ofRunApp( new testApp());


i got

src/main.cpp: In function ‘int main()’:
src/main.cpp:8:21: error: cannot declare variable ‘window’ to be of abstract type ‘ofAppGLFWWindow’
../../../libs/openFrameworks/app/ofAppGLFWWindow.h:31:7: note: because the following virtual functions are pure within ‘ofAppGLFWWindow’:
../../../libs/openFrameworks/app/ofAppBaseWindow.h:15:15: note: virtual void ofAppBaseWindow::setupOpenGL(int, int, ofWindowMode)
../../../libs/openFrameworks/app/ofAppBaseWindow.h:36:15: note: virtual bool ofAppBaseWindow::doesHWOrientation()
make[1]: *** [obj/linux64/Release/src/main.o] Errore 1
make: *** [Release] Errore 2

because these 2 virtual functions are missed(doesHWOrientation()) or different setupOpenGL()
to fix add

bool doesHWOrientation(){
return false;

in ofAppGLFWWindow.h

and change

void setupOpenGL(int w, int h, int screenMode)


setupOpenGL(int, int, ofWindowMode)

in ofAppGLFWWindow.cpp and ofAppGLFWWindow.h

Anyway after fixing this i got a sigfault:

gdb ./example-glfw
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /home/walter/OF/openFrameworks/examples/glfw/example-glfw/bin/example-glfw...done.
(gdb) run
Starting program: /home/walter/OF/openFrameworks/examples/glfw/example-glfw/bin/example-glfw
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/".

Program received signal SIGSEGV, Segmentation fault.
0x00000000004d9daf in _glfwPlatformGetWindowSize ()


I'm quite interested to try this out, but when I checkout @arturoc's branch I seem to be missing ofAppGLFWWindow.* and can't get the multiwindow example to compile. Am I missing something?

kalwalt commented Apr 18, 2013

I'm quite interested to try this out, but when I checkout @arturoc's branch I seem to be missing ofAppGLFWWindow.* and can't get the multiwindow example to compile. Am I missing something?

hi @gameoverhack i have also had this issue. I thought that i made something wrong with git. But in the web repo there are the ofAppGLFWWindow.* files. So i can't give an answer to this. I solved htat problem doing copy and paste from the github repo. At the end i get the error above. Tell me if you solved the problem in this way.
Maybe @arturoc can give us some insights.

p.s also you need to do the things explained above by me ( add the doesHWOrientation() and changes in the setupOpenGL function)

arturoc commented Apr 18, 2013

ofAppGLFWWindow is not used anymore so you can remove it safely from the
projects and any reference to it

On 04/18/2013 08:51 PM, Walter Perdan wrote:

I'm quite interested to try this out, but when I checkout @arturoc
<>'s branch I seem to be missing
ofAppGLFWWindow.* and can't get the multiwindow example to compile.
Am I missing something?

hi @gameoverhack i have also had this
issue. I thought that i made something wrong with git. But in the web
repo there are the ofAppGLFWWindow.* files. So i can't give an answer to
this. I solved htat problem doing copy and paste from the github repo.
At the end i get the error above. Tell me if you solved the problem in
this way.

Reply to this email directly or view it on GitHub
#1470 (comment).

kalwalt commented Apr 19, 2013

@arturoc ok now the code run! but need some addiction and changes

need to add a flags -fpermissive in adding it to config.make do nothing,
something like this:

PLATFORM_CFLAGS += -fexceptions
PLATFORM_CFLAGS += -fpermissive

and in examples/other/multiwindowEaxmple/src/main.cpp


ofSetupOpenGL(ofGetWindowManager(), 1024,768, OF_WINDOW);


ofSetupOpenGL( 1024,768, OF_WINDOW);

and in examples/other/multiwindowEaxmple/src/testApp.h

class windowRenderer: public ofWindowListener {


class windowRenderer: public ofBaseApp, public ofWindowEvents {

this make the application to run. But ofEvents seems to not works properly (scrolling) and mouse events; and i can't see the second bitmap string "THIS IS A SECONDARY WINDOW" nor the black rect in the secondary window.

i tired the OF_FULLSCREEN and it works , the main bar stay until you click with the mouse on the window and the it disappear.
Now i'm very curious to see and to test it again in arm.

arturoc commented Apr 19, 2013

are you using the latest in my branch feature-elinuxProgrammableGLFW? i had some of those problems with the programmable renderer but they are fixed now, mainly the problem where you don't get anything drawn working in the second window

kalwalt commented Apr 19, 2013

are you using the latest in my branch feature-elinuxProgrammableGLFW? i had some of those problems with the programmable renderer but they are fixed now, mainly the problem where you don't get anything drawn working in the second window

@arturoc should be the latest. but i will check it later. thanks!

kalwalt commented Apr 21, 2013

@arturoc i have the latest. see the git log:

git log
commit d57cedd
Author: arturo
Date: Wed Apr 10 13:09:54 2013 +0200

ofAppGlutWindow: setupOpenGL correct type

commit a758bd3
Author: arturo
Date: Wed Apr 10 13:09:25 2013 +0200

window: fix seetup and mouseDragged events

commit 7e50fe0
Author: arturo
Date: Mon Apr 8 22:23:18 2013 +0200

ofWindow.cpp: add separators

commit a25addb
Author: arturo
Date: Mon Apr 8 22:09:07 2013 +0200

ofShader: first default attribute as 0, fixes performance problem in osx


maybe did you miss to push some commits?


Is there an example of how to use a glfw multiwindow application? Seems like the multiwindow example is very out of date in this branch...


This is the only example atm Although old the syntax should still be that way.


Yep @arturoc has that example in his branch - but after several attempts to get it to work it looks like the API has been changed significantly. Have you tried running that example using arturo's branch?


is it possible to get a status report on this PR? :) @underdoeg @arturoc

are there any major issues left? @ofTheo said fullscreen is still problematic?

ofTheo commented Jun 2, 2013

as kyle said - there is a strong feeling we should merge this in and then get the missing libs / tweaks etc added as we need a good amount of time to have OF testing this.

Any major issues standing in the way?

arturoc commented Jun 2, 2013

hey, this is not ready to be merged there's several bugs in this branch. i've fixed some of them in my programmableGLFW branch but i'm also changing the architecture since there's things that can be done in a simpler way that done here. Also this assumes shared contexts and some objects can't be shared like fbos, shaders... this is problematic with the new programmable renderer since it needs shaders so somehow there should be a renderer per window.

anyway i'm working on it but my feeling is that we should postpone this for next release instead of 0.8

arturoc commented Jun 2, 2013

also there's a simpler glfw class in the programmableGL branch that is going to be merged soon, that doesn't have multiwindow support but everything is fixed there, fullscreen... so i think it's better to ship 0.8 with GLFW support but without mutliwindow by now


I think it is a good idea to ship .8 with GFLW support but not the multiwindow part yet. That way we can split this rather big PR into two steps. And are presented with fewer problems with the next release.


@arturoc If I understand you correctly you sssuggest to always have one renderer per window? Is there also a way to still share the contexts for eg images ?

arturoc commented Jun 3, 2013

yes, any object that is shareable will still be if we have 1 renderer per window since the context is still shared. The only difference is that setting a renderer per window creates the default shaders for each window.


In light of the upcoming bugfixing drive towards 0.8 this weekend, could we get an update on the status of this PR? Will we be able to finish/merge this soon?


@bilderbuchi This branch is not going to be merged since it is obsolete with @arturoc's branch. Should I delete the PR? Will this preserve the discussion in this thread?


I'll just close it, discussion will be preserved. :-)

@bilderbuchi bilderbuchi closed this Jul 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment