I’ve had to fiddle around with multiple windows for different XDisplays. This has gotten much easier than it used to be which is great.
Actually the only thing that makes it complicated ATM is this part
The size of the render surface is internally bound to a call to the currently active window. This makes sense but makes things really complicated. What I had to do again is mimicking an ofAppBaseWindow with a custom class and return the size of the active window. Easy enough but I somehow felt like this could be done differently? Did I miss something? Or should we implement some call like ofPushRenderSurface(ofRectangle) or something similar?
not completely sure what you mean, but when i was looking into implementing multiwindow, i realized that the way to go is having one renderer per window so i think this is fine, the architecture will change a bit but this particular thing is ok i think, since every window will have it’s own renderer and each renderer it’s own matrix stack associated to that window
btw, that’s because shared contexts can’t share some resources like shaders so multiwindow with programmable GL won’t work unless we have a renderer per window
yes for the final multiwindow implementation we will need multiple renderers. But for this project it was sufficent to hack something in.
The windows had different sizes and what I did was setting up the screen with a viewport before rendering the contents. That worked but OF internally flips the Y coordinates and that was the problem. Every Y coordinate in a 2D space is somehow internally converted into
windowHeight - y which ended up in an offset that came from the main window.
Even if I had created an opengl renderer for each screen, I don’t know how to deal with the reference to the main window within the matrixStack. That’s why I was wondering if a renderer has to know about windows. Shouldn’t it be more like a window creates a render surface and sets the surface dimensions on window resize?
yes that’s how it should work, right now the renderer is getting a pointer to the window which is kind of hacky, in the future each window will create it’s own renderer or passed one on creation or something similar
makes sense and one should not fight a hacky implementation with another hack
Are you already working on this? Or what priority does it have atm?
i started something that was supposed to go with 0.8 but found the architecture changes kind of complex so i left it for another time, it was mostly based on your implementation but i was trying to get rid of the ofWindowManager
yes, the window manager was more some sort of workaround to the core concepts. although I think that there should be some central entity that knows what windows are available but it shouldn’t do all the routing stuff.
What I found really difficult as well was how to handle mouse and keyboard events.