Wrong Scissor Mode and broken FrameEvents
creeperlv opened this issue · 9 comments
I believe the old EnableScissor(...) work more correctly than current one.
As you can see, the first screenshot is from commit 08a68d3c2d0ecac060c2a341232ddb901aecd4dc the second one is from 6ed53c713c453c9398428154b993ef99b9145920. It looks the old one works for me.
Currently I have daul monitor setup, both of them are 1080P and DPI is 125%.
Besides, I believe at line 446, it should be
io.AddKeyEvent(keyItr.Value, Raylib.IsKeyDown(keyItr.Key));
instead of current one. Current one will crash directly.
The key event code was removed, it's not needed.
For your scissor issue, do you init your window in high DPI mode?
The key event code was removed, it's not needed.
That's great!
For your scissor issue, do you init your window in high DPI mode?
The screenshot is capture from the simeple-example project, with no modification of init code.
I can confirm that Task Manager reports DPI Awareness is Per-Monitor (v2)
does it work if you remove the scale from the computation?
does it work if you remove the scale from the computation?
Currently I have no idea about where scale is involved in the computation, however, I can confirm that commit 5c1d75dd188ff02cfa1830704453508612a8adb5 is working correctly on my machine where 0b2812fd8a4ac5a25f3dd3df41c442e56a933d60 and 6ed53c713c453c9398428154b993ef99b9145920 are not.
the scale is the multiplication of the sizes by io.DisplayFramebufferScale
I have tried a similar setup to yours and do not have an issue at 125% scale.
Please try the following.
- Set a breakpoint in the scissor function and see if the display size that is sent to the scissor is in real pixels or scaled pixels?
- remove the multiplication by io.DisplayFramebufferScale and see if that changes anything.
that change was to fix another reported bug, so I don't just want to blindly revert it.
I believe that's the problem. For first call, Width and Height passed to the function are 1280 and 800 that matches pixel size I grabbed from screenshot, also, io.DisplayFramebufferScale reports correct scale value that is 1.25. By removing multiplication of io.DisplayFramebufferScale, scissoring works fine on machine. I am not sure what changed about DPI processing in Raylib side, but I can also confirm that by calling Raylib.DrawRectangle(0,0,1280,800,Color.WHITE);, the white rectangle will cover the whole window.
Besides, some system information might be useful here:
OS: Windows 11 Build 22631.2861
GPU: Nvidia RTX 4060
Monitor: 1080P at 125% DPI
Hope information above is useful for the problem.
I have updated the the library with a change that I think will fix this issue. It no longer applies the DPI scale for non-high DPI display mode. This seems to have resolved the issue for me (I was finally able to duplicate it in the C++ version).
Please get latest code and tell me if it fixes the issue. If so then I'll publish an updated nuget package with the fix.
Had the exact same issue with two monitors 175% and 125%. The latest code fixed the scissor issue reported above.
However, another issue that seems to come from the scissor code is still present. When I maximize the window, some parts dissappear.
If I comment out the EnableScissor(...) call, the problem goes away
I can confirm that I am experiencing same behavior as @tibimunteanu describes.
However, I believe this behavior was caused by line 346 at rlImGui.cs. When the window is maximized, I think we should still use Raylib.GetScreenWidth() and Raylib.GetScreenHeight(). Removing the condition || Raylib.IsWindowMaximized() do fix this problem.