Hosting surfaces on non-Window, and factoring out message loop

[mediabuff]

1. The library assumes all rendering in Native top-level windows there are other surfaces the - like composition visuals (IVisual), and swap panels etc.
2. the main game loop is owned by the the library this should be factored out for the library to be used as a component
3. UWP support and Core windows support - additionally IVisual, Swap panel in uwp
4. support Google/Angele/GLES under windows.

[LukasBanana]

Is that a question or request for new features? Please note that I'm not actively working on this project anymore and only do basic maintenance like bug fixing. If you have changes on your own you can file a pull request.

[mediabuff]

Thanks for prompt response. These are feature requests.

[beldenfox]

1. On Windows and Linux the library can draw on child windows, you just have to create a custom Surface class which hands over the child window in the NativeHandle structure. On the Mac the NativeHandle points to an NSWindow but I was able to fix that without too much effort in my fork where you can create a RenderContext on any NSView (and for Metal you can also use a CAMetalLayer).
2. On Windows and Linux you can already use your own message loop. On Mac you can run your own loop but this will cause LLGL::Window surfaces to misbehave; custom surfaces that use standard NSResponder mechanisms would work. I removed this limitation in my fork.
3. I'm not that familiar with UWP but it seems the main issue is that there's no route for handing the surface over to the RenderContext to build the swap chain. This could be remedied by expanding the NativeHandle to include an optional IUnknown pointer; if provided the RenderContext could query it to determine which swap chain creation call to use. I don't know if there are other more substantial differences between running a DirectX swap chain on top of a UWP surface rather than an HWND.

[LukasBanana]

@beldenfox I like what you did with the Application interface in your fork. Whenever I find the time I might merge that into the master branch.

[beldenfox]

@LukasBanana I'm glad you approve. Taking just the Application interface is a little involved on the Mac. To make it work there needs to be an NSResponder handling events. At one point in my commit history (now lost) the responder was the NSWindow and I had made no changes to the renderers. But the whole point was to move the context down to the NSView level and now that's where the responder code lives and what the NativeHandle points to. That required altering the renderers, particularly the Metal renderer which now manages its own CAMetalLayer directly. I could assemble a PR that implemented Application without changing the NativeHandler or renderers if you want.

[LukasBanana]

That sounds great. Little change to the existing interfaces would be preferable but some change will be inevitable of course.

What I would like to keep is the ability to create a default surface. I saw in your fork you require a Surface object and don't accept a null pointer in SetSurface. The idea was to make it easy if you want a simple application that only uses a single default window/canvas to simplify the initialization process.

Besides that, your changes regarding the differentiation between resolution and window size make perfectly sense, too. I think last time I saw an LLGL example on a 4K monitor in Windows the render content occupied only a 4th of the window. Perhaps because I didn't use DXGI_SCALING_STRETCH.

[beldenfox]

Creating a default surface is problematic when all you have is a resolution in hand. The old code would create a Window of that size (interpreting the resolution not as pixels but as window units) and then set the back buffer size (in pixels) to the same value. That's the sort of behavior that could cause the code to render in only one quarter of the window or at a lower resolution than expected. (Still, I'm surprised you saw issues on Windows, I thought the OS scaled everything up unless the app advertised itself as high-dpi aware.) I'm also don't like having RenderContext dependent on the Window or Canvas class. A client that wants to use a different application toolkit (like SDL2) should be able to shed the LLGL Window, Canvas, and Display classes entirely.

[LukasBanana]

Better late than never but this should be mostly fixed with 5ee8cc3 and 651c31e.