Multi-window support in Platform::Application classes

[mosra]

As requested by @LB--, it would be great to have multi-window support in the application classes (two windows sharing the same GL context). I have two and half mutually incompatible ideas how to handle it and it would be great to hear some opinions on these:

• Adding a window using addWindow(WindowConfiguration config) which would return (sequential) window ID. Then each event handler would get that window ID parameter -- that's how SDL is doing it, the implementation would be very easy although I need to break some APIs (in a good way). It allows the users to stay in the same class so they can share the resources but then they need to do a lot of ifs in each event handler, which is very ugly.
• Improvement of the above where one would add a window using addWindow(WindowConfiguration config, T ...eventHandlers), where eventHandlers would be pointers to member functions which they want to use to handle the events. For example &MyApplication::mousePressEventDebugWindow if a user wants to use different function for that window, &MyApplication::mousePressEvent if a user wants to handle events of more windows in the same function, or not mentioning any function if they don't want to handle given event at all. It still allows to stay in the same class, but gives a lot of flexibility on top. Is handling two windows with a single class good or not?
• Completely different option is to create something like Sdl2ApplicationWindow, which would be a base class of Sdl2Application and would contain only the event handling interfaces. That effectively means rewriting all application classes, but seems to be quite straightforward and "object oriented". It separates each window into a dedicated instance (which might be a good thing), however it would not be possible to handle events from more windows in a single instance/function like in the options above.

[LB--]

I definitely do not like option 2 - it feels really awkward to both have a class for the main window and then just a set of arbitrary functions for other windows.

I like both option 1 and option 3 - is there maybe some way to combine them? It makes sense to have one Application instance and multiple Window instances - maybe we could take advantage of multiple inheritance somehow? For example, maybe MyApplication can inherit from both Platform::Application and Platform::Window, which would make it very easy to update existing code (just inherit Platform::Window to fix all or most compilation errors) and also allow for additional windows to have their own class by only inheriting Platform::Window and thus keep only one application instance.

[mosra]

Maybe I wasn't very clear: option 3 won't involve any backwards-incompatible changes for the user. The Platform::Application gets split into Platform::ApplicationWindow and Platform::Application, but Platform::Application: would inherit from Platform::ApplicationWindows so the default behavior stays the same -- when you instantiate an application, you get also one window by default (because it makes sense to do so).

I guess that's the cleanest option, then :)

[LB--]

Ah, I see - yes, option 3 sounds the best then :)

[mosra]

Because other tasks got more priority recently, I'm not able to work on this right now. The in-progress implementation was pushed into multiwindow branch, a few crucial pieces are still missing.

[LB--]

No worries :)

[staticfloat]

Any update on this? I'm currently using Magnum to do realtime plotting of large amounts of data for scientific research (probably not something you expected Magnum to be used for, but such is life!) and it'd be very useful to have multiple windows available to a process. My solution right now is to have multiple processes that communicate the data to eachother with zmq, but that's certainly more work (for me) than just having multiple windows.

[mosra]

I'll try to look into it this week. Because such code is hardly testable in an automatic manner, I wanted to create also some example for it to verify usability of the APIs.

[mosra]

168 now contains a WIP implementation. There are still some things to iron out, will merge once all boxes are ticked.

[mosra]

For the record, random internet info that proved to be very useful recently when making a two-window app on Windows run 60 FPS and not 30:

• https://stackoverflow.com/a/29622141
• https://bitbucket.org/!api/2.0/snippets/dark_sylinc/y8aGn/1ffeace824f6ce539f2eee31f63ab3261cda8ec6/files/OpenGL%20multi-mon%20notes

In particular:

• rendering everything first, then doing buffer swap (otherwise the commands submitted later will make the app miss the VSync)
• enabling VSync only for one of the windows (otherwise the framerate drops to half/quarter/...)
• making GL context current on given window before doing buffer swap

[LB--]

I wonder what happens when two windows are created on different monitors and one of the monitors has a different refresh rate? I have such a setup myself, it'll be interesting to see which one it considers to be the vsync one.

[mosra]

I have no idea, frankly :) If one is let's say 60 Hz and the other is 90 Hz, then rendering at 90 Hz would make the 60 Hz display stutter every second frame, if rendering at 60 Hz, the 90 Hz would stutter every frame.

[williamjcm]

I have a 75Hz VGA monitor, but sadly, the only two laptops I own that have a VGA connector can't be used for testing. :/

[BoyeGuillaume]

Hello, and thank you for quick response on issue #426.

As said in this issue, I have been working with Magnum library for an application and I need to use multiple windows interface. I have made a interface bypassing the Sdl2Application class, using directly the SDL APIs. When my software continue after my windows creation and the openGL context configuration and creation, I have got GL::Context::current(): no current context error raised by the CORRADE_ASSERT, within Context.cpp line 560. I wonder how to link the SDL library with the Magnum ones using the Platform::GLContext.

Is it possible then to get only one openGL context and switching between multiples windows, as if we were in normal SDL APIs implementation like in the forum https://stackoverflow.com/questions/22227811/sdl2-and-opengl-functions-with-two-windows

[mosra]

You have two options:

• Use SDL / GLFW / ... directly, as you do now. Then you however need to instantiate Platform::GLContext by hand. Docs on that and here's an example that uses plain GLFW.
• Use the Sdl2Application class for the main window and create additional windows directly using SDL APIs. I'd say this variant would be more straightforward, as you get most of the SDL APIs wrapped in a Magnum-compatible way (and things like HiDPI support implemented already). Have a look at https://github.com/mosra/magnum/pull/168 for one of possible ways how to approach this.

Hope this helps! :)

[BoyeGuillaume]

Thank you

[visigoth]

i couldn't find stuff in the docs about this: if multi-window support is still NYI, what exactly is a Screen in Magnum? is it just a unique viewport that is to be drawn within the application window?

[mosra]

@visigoth you mean this, right? The docs are quite lacking there, sorry for that.

It allows the application to switch between independent ... uhh, screens, (such as a loading screen, settings screen or pause screen) inside a single window, and redirect events to just one of them at a time without the application logic having to manage that via giant if cascades on its own.