DPI Scaling Issues

[HACKERALERT]

Hi,

There are multiple DPI scaling issues I believe. For example, the image on the left is a normal display, and the one on the right is a high DPI (factor 2) display. Notice that there's a larger gap in the high DPI display screenshot.

In addition, I have to use multiple hacks to get the scaling correct. For example, I have to do divide by dpi to get the correct scaling on some types of widgets, otherwise, on the high DPI display, it will be too big:

giu.InputText(&password).Flags(passwordState).Size(302/dpi)

giu.Button(s("Change")).Size(bw/dpi, 0).OnClick(func() {

giu.Dummy(size/dpi, 0).Build()

giu.ProgressBar(shredProgress).Overlay(shredOverlay).Size(size/dpi, 0),

There's even a line where I had to divide twice to get things to work:

giu.InputText(&outputFile).Size(dw / dpi / dpi).Flags(giu.InputTextFlagsReadOnly),

It might be a good idea to fix this so that giu looks consistent on all displays without having to divide by dpi. I'm not sure if this is an Imgui limitation, but it's worth a look into because it will make development with giu a lot easier! For reference, my entire UI code is here: https://github.com/HACKERALERT/Picocrypt/blob/main/src/unstable/Picocrypt.go#L225. Thank you!

[AllenDang]

@HACKERALERT The root cause is at the time giu invent it's own DPI scaling mechanism, imgui doesn't have one. And for recent version of imgui, it comes with a inside DPI scaling, that causes the size is scaled twice... I may need more time to fix this as you know, a national festivel is coming.

[AllenDang]

@HACKERALERT Try again with newest code. I removed all dpi scaling from giu side.

[HACKERALERT]

Not quite. Perhaps ImGui is having issues? Normal DPI: High DPI:

[macbutch]

@AllenDang I just updated to the latest code on master - it looks quite nice, very minimal changes required, but I noticed that I can no longer call g.Context.GetPlatform().GetContentScale(). I haven't tested yet (will do tomorrow) but do I no longer need to worry about scaling or is there another way now? thanks again!

[AllenDang]

@macbutch Pls help me to do a test to see whether DPI scaling works. Many thanks!

[HACKERALERT]

@AllenDang just gave the master branch a try, it still has the same issue and looks the same as my second picture. Seems like a difficult problem to solve, I guess. Good luck!

[macbutch]

@AllenDang just did a quick test - the size of the window is correct but everything inside is tiny. Happy to do more testing as it evolves but this latest build doesn't seem to scale for me. Is there something I need to add?

Edit to add: I tested yesterday on MacOS and everything is fine there (but that was always the case); it's just Windows with High DPI displays.

[AllenDang]

@macbutch I just pushed a fix, can you try again with newest master branch?

[macbutch]

@AllenDang sure, give me a few hours and I'll report back. Thank you!

[macbutch]

@AllenDang I'll test more later but it is definitely much better. I think maybe something isn't quite right with padding but I only took a glance. More later!

[HACKERALERT]

@AllenDang Almost there! Only a few more issues to sort out 😄 .

[macbutch]

OK. This latest one is much better than before but I have a few issues with the master branch right now:

1. some spaces and sizes come out differently on High DPI: an image/icon is about half the size and in another case some buttons overflow. It's very close otherwise but there is less padding of text inside buttons on Windows vs MacOS for me.
2. There seems to be some change in behaviour for Popups which I've not quite understood and one of my Popups closes unexpectedly sometimes.

I could likely live with (or workaround) the first issue but the second is quite annoying (popup closing while still being used). Has anything changed there?

[macbutch]

@AllenDang A tiny bit more feedback but I'm away from my Windows computer for a few days and can't test more until the weekend. It's much improved but there are a few cases where things aren't quite the right size. So where I've got some careful calculations of size etc to make sure everything fits on MacOS those things don't quite come out the same on Windows (so I end up with scrolls bars where I don't want them, etc). I've also noticed that images come out smaller (this isn't a big deal for my app but I think that Image still needs to be scaled up somehow). I'll report more when I can.

[macbutch]

@AllenDang wanted to report one thing that I've nailed down fairly solidly now. Most things are working well but one thing that I found is not quite right is that Images show up at 1/2 the size I'd expect. I am able to workaround this fairly easily like so:

    logoWidget := g.ImageWithRgba(Logo)
    b := Logo.Bounds()
    logoWidget.Size(float32(b.Dx())/(dpi*dpi), float32(b.Dy())/(dpi*dpi))

Note that I'm squaring the dpi. I'm not sure why that's necessary but it seems to give the right result. Hope this is useful.

I have some other issues but I'll report more later. I haven't quite tracked down exactly what is going on.

Thanks again

[AllenDang]

@macbutch Thanks! Let's nail things one by one. Try newest master, size of image widget should be scaled.

[macbutch]

@AllenDang fantastic, thank you, trying it now.

[macbutch]

@AllenDang confirmed! we are making progress! I have to call Size() (the default is still off) but this is a big improvement. I'm following along as best I can to understand what's changing. I need to check on normal Windows too. Let me do that and report back.

Comparing a Surface Pro to MacOS I'm now down to differences in padding/size. I'm trying to centre and align things. I've read through some of the alignment code etc so I understand the basic ideas but I find that things don't quite work out the same and I need to adjust manually for Windows.

[AllenDang]

@macbutch Thanks for the confirmation, :P. I don't have a high DPI windows machine by my side, so your testing is highly valuable.

[macbutch]

@AllenDang Happy to test when I can! I've borrowed my wife's laptop and I'm sitting here with 2x Windows + MacOS to compare all three.

Now I'm down to something that may be a bit trickier -- possibly more user error by me. I've got some buttons and labels that I want to arrange on one line (a Row) with some buttons aligned left and some go to the right. I use a Dummy between them. I create the buttons and labels then get the width of the MasterWindow and then subtract the result of GetWidthWidth() for each button/label to size the Dummy.

It looks like this:

func makeSpacer(width int, widgets ...g.Widget) g.Widget {
    size := float32(width)
    pad, _ := g.GetItemSpacing()
    size -= pad * float32(len(widgets)+2)
    for _, w := range widgets {
        size -= g.GetWidgetWidth(w)
    }
    if size < 0 {
        return nothing()
    }
    return g.Dummy(size/dpi, 0)
}

That doesn't give quite the result I want on any platform 😆 so what I do on MacOS is multiply the width parameter by 0.9 and then, on Windows, it's 1.1. Any ideas what I'm doing wrong? I can probably work with this but clearly something isn't quite right.

[macbutch]

Oh and that's not even close on Windows without High DPI.

[AllenDang]

@macbutch You could get DPI scaling factor by invoke giu.Context.GetPlatform().GetContentScale(). Use it to test the scaling will be more accurate.

[macbutch]

@AllenDang that's what I'm using for the dpi variable on the last line. It's a global (shame on me) but I'm just hacking here. I don't understand why it's coming out differently on each platform. I'll keep chipping away - it will start to make sense at some point.