bjoern
November 15, 2023, 2:04pm
1
when moving a window between screens with different scaling settings.
What’s currently happening:
Start application on primary display with scaling set to 150%
Move it to a secondary display with scaling set to 100%
The widgets stay at the same size and are “cut off”.
Instead they should rescale, to the same size they’d have when started on a (primary) display set to 100%.
I think I tracked down the issue (to a certain point). VL.ImGui.Skia.ToSkiaLayer
already does factor in the display scaling. For that it uses DipFactor()
in VL.UI.Core.DipHelpers
.
Unfortunately this method seems only to return the DIPFactor of the primary monitor.
But the factor should be dependent on the window ImGui is rendered into (and on which display it’s located).
This works and dynamically updates when moving the window to another monitor for example:
I also came accross that one:
Could something like that be added to ToSkiaLayer
(or where necessary) or can we get access to the scaling parameter so it can be set patch-wise?
@Elias
DPI.vl (19.7 KB)
6 Likes
bjoern
November 15, 2023, 2:10pm
2
Somewhat related I guess:
Currently trying to set the skia-renderer position and scale inside the patch. First thing, I do not get: What is the unit of the width/height-settings rectangle? Can’t be pixel, since my screen is 4k and the renderer is bigger than 100px. One...
Reading time: 1 mins 🕑
Likes: 10 ❤
Elias
November 16, 2023, 11:46am
3
We’ll have to add some sort of abstraction to do this or we end up with another windows dependency right in the core. That’s why it will take some thinking and can’t be done straight away. But since UI is on the horizon again it might be tackled then since we for sure will hit the same issue.
3 Likes
bjoern
November 16, 2023, 12:04pm
4
Just hacked this into ToSkiaLayer:
public unsafe ToSkiaLayer(float scaling = 1.0f)
{
_context = new SkiaContext();
using (_context.MakeCurrent())
{
_io = ImGui.GetIO();
_io.NativePtr->IniFilename = null;
_renderContext = RenderContext.ForCurrentThread();
_fontPaint = new Handle<SKPaint>(new SKPaint());
//var scaling = VL.UI.Core.DIPHelpers.DIPFactor();
updateScaling(fontScaling: scaling, uiScaling: scaling);
}
}
Unfortunately it somehow only affects the FontScaling but not the UIScaling .
But could this be made to work and added in the meantime until you finished thinking up the proper solution?
bjoern
November 16, 2023, 12:13pm
5
Mentioned this in the chat already but still for reference:
opened 09:30AM - 12 Mar 18 UTC
font/text
backends
dpi
multi-viewports
I've been toying with DPI handling recently. Part of this is motivated by the wo… rk on Multiple Viewport #1542 which are making this topic trickier than it already was before. Some (early and experimental) commits are being pushed to the Viewport branch.
This is mostly a thread to link commits too, write down some notes and eventually attract feedback, suggestion or solutions.
The work involve
- imgui-side changes (how does it affects fonts? style? various sizes and positions)
- platform-side work
Single viewport DPI handling can be handled by the application at the moment (by using a larger font and scaling e.g. the style appropriately), however we ought to clarify and simplify the work that needs to be done, and support it in the examples. The position/size of windows relative to their viewport also ideally ought to be scaled.
Multi viewport DPI handling involve changing those depending on where we are located: moving an imgui window from screen 1 to screen 2 can affect sizing. Effectively calling Begin() can put you in a different DPI context. It's trickier to solve because e.g. our font system currently don't allow for arbitrary quality scaling so we may have to come up with scheme to make that more transparent eventually. Likewise for style (and scaling style sizes is a lossy operation).
Platform-side: At the moment I am focusing on Windows. I imagine (hope) MacOS will be easier but I don't have reliable access to a Mac right now. I don't know about Linux. The platform dependent part of the work is not very complex. Under Windows, consideration of backward compatibility with older versions of Windows and Windows SDK makes the code more messy, but nothing really hard.
system
Closed
November 15, 2024, 12:14pm
6
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.