[VL.ImGui.Stride.Viewports]

[kopffarben]

PR Details

Viewports support for VL.Imgui.Stride

Description

This is an attempt to support ImGui viewports in VL.

It already works quite well, there are a few small things that do not work satisfactorily yet.

IssueTracker: https://github.com/kopffarben/VL.StandardLibs/issues

The previous features should all still work. Not 100 percent sure.

The problem with the Skia input should also be fixed. I think Kairos is still working, but I'm not quite sure as I don't know exactly how it should behave.

In general, it could be cleaned up again, I'm also not completely satisfied with the naming of some classes ... but in principle it's good for now. I'm also not quite sure if this is the best solution for some things.

I would be very happy about a code review.

Types of changes

• [ ] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

[kopffarben]

Because the window out and in again bug, i.e. losing the input handling, I will also take another close look at it. I'm just relatively busy at the moment. But hopefully I'll get back to it tonight or in the next few days. I think it also needs another cleanup

[azeno]

@kopffarben My last commit (linked above) seems to have fixed #672 as well. However there was also that boolean flag I had to add as a workaround back in April which I now managed to get rid of by using the same code path for notifications as the normal Skia render path takes (see linked commit in #672, 2b92219b68aa61730b06b8ac38ca5ab6399caaab). I didn't merge it back to main yet because of our discussion further up which is all about that line. You said in docking branch it expects the screen space coordinates in AddMousePosEvent - but then I wonder how this will work together with current approach / approach taken in my new branch where we feed the PositionInWorldSpace which to my understanding takes those Skia viewports into account.

[kopffarben]

the AddMousePosEvent is only set if ImGui is not in viewport mode. If ImGui is in viewport mode, the screen space mouse position is set every frame in ImGuiWindows.

private void SetPerFrameImGuiData()
{
    unsafe
    { 
        int x, y;
        uint buttons = global::Stride.Graphics.SDL.Window.SDL.GetGlobalMouseState(&x, &y);
        _strideDeviceContext.IO.MouseDown[0] = (buttons & 0b0001) != 0;
        _strideDeviceContext.IO.MouseDown[1] = (buttons & 0b0010) != 0;
        _strideDeviceContext.IO.MouseDown[2] = (buttons & 0b0100) != 0;
        _strideDeviceContext.IO.MousePos = new Vector2(x, y);
    }

    _strideDeviceContext.IO.DisplaySize = new Vector2(mainViewportWindow.Size.X, mainViewportWindow.Size.Y);
    _strideDeviceContext.IO.DisplayFramebufferScale = new Vector2(1.0f, 1.0f);

    ImGui.GetPlatformIO().Viewports[0].Pos = new Vector2(mainViewportWindow.Position.X, mainViewportWindow.Position.Y);    
    ImGui.GetPlatformIO().Viewports[0].Size = new Vector2(mainViewportWindow.Size.X, mainViewportWindow.Size.Y);
}

So it should not break the current approach

[kopffarben]

SO I fixed most of it for now, merged main and the bugfix. The problem with pulling the window in and out still exists.

I lose the input source or the appropriate viewport after dragging in and out a few times. Sometimes it goes faster ... but I don't have enough time right now to investigate it more closely. But I will keep at it.