internal/ui: a window size is not appropriate on i3wm

[SolsticeSpectrum]

Ebitengine Version

2.7.0

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

Go Version (go version)

1.22.2

What steps will reproduce the problem?

Switch from 2.6.7 to 2.7.0, it probably only happens if the window is initially very small but that's intended and it worked flawlessly on 2.6.7

What is the expected result?

The size of the window should stay the same across the versions no matter of the initial size

What happens instead?

The window is larger
Here is a before and after

The smaller one is compiled with version 2.6.7 and the other one with 2.7.0

Anything else you feel useful to add?

The problem occurs in this program https://github.com/crgimenes/neko
But I already isolated the issue and can tell for certain that it's an issue with this library specifically
Here is an issue I opened in that repository crgimenes/neko#24 (comment)

[hajimehoshi]

I'll take a look

[SolsticeSpectrum]

@hajimehoshi Thanks, for the time being I downgraded to 2.6.7 on my side, however this should be only temporary solution as I can't use X11ClassName and X11InstanceName on 2.6.7 making it less intuitive to target with picom and i3wm
I can use title and wm_name for now

EDIT: The program also allows for fractional values but with 2.7.0, it seems like there might be minimum window size set somewhere causing this behavior

Here is 2.6.7 for comparassion

[hajimehoshi]

I couldn't reproduce the issue with my desktop:

       _,met$$$$$gg.          parallels@debian-gnu-linux-12 
    ,g$$$$$$$$$$$$$$$P.       ----------------------------- 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux 12 (bookworm) aarch64 
 ,$$P'              `$$$.     Host: Parallels ARM Virtual Machine 0.1 
',$$P       ,ggs.     `$$b:   Kernel: 6.1.0-9-arm64 
`d$$'     ,$P"'   .    $$$    Uptime: 3 mins 
 $$P      d$'     ,    $$P    Packages: 1905 (dpkg) 
 $$:      $$.   -    ,d$$'    Shell: bash 5.2.15 
 $$;      Y$b._   _,d$P'      Resolution: 2560x1600 
 Y$$.    `.`"Y$$$$P"'         DE: Cinnamon 5.6.8 
 `$$b      "-.__              WM: Mutter (Muffin) 
  `Y$$                        WM Theme: cinnamon (Default) 
   `Y$$.                      Theme: Adwaita [GTK2/3] 
     `$$b.                    Icons: gnome [GTK2/3] 
       `Y$$b.                 Terminal: gnome-terminal 
          `"Y$b._             CPU: (2) 
              `"""            GPU: 00:0a.0 Red Hat, Inc. Virtio 1.0 GPU 
                              Memory: 1219MiB / 1978MiB

What is your display's scale?

#2225 might be related. /CC @tinne26

EDIT: The program also allows for fractional values but with 2.7.0, it seems like there might be minimum window size set somewhere causing this behavior

I could reproduce a strange rendering with 0.5. I'll take a look further. In this case, both Ebitengine 2.6 and 2.7 caused a strange rendering on my machine. This seems a bug anyway so I'll take a look.

[SolsticeSpectrum]

@hajimehoshi

As for scale I suppose I would have 100%, I don't have the gnome tool you have, I use xrandr

EDIT: Yeah I don't have any, it's 0

[hajimehoshi]

Hmm, I couldn't reproduce your issue with 100% scaling...

$ gsettings get org.gnome.desktop.interface scaling-factor
uint32 0

Would it be possible to git-bisect what was the culprit Ebitengine commit to you?

[SolsticeSpectrum]

@hajimehoshi I honestly wanted to do this at some point so yeah I can do that, just gotta google how to import packages from folder

[hajimehoshi]

@DarkReaper231 Thanks. You can do that by adding this line in go.mod:

replace github.com/hajimehoshi/ebiten/v2 => /path/to/local/ebiten

[SolsticeSpectrum]

@hajimehoshi Actually there is an easier way of just doing go get github.com/hajimehoshi/ebiten/v2@2da56c00c8363ec3b5ff785786e53d9db5834636
And go will automatically downgrade/upgrade go.sum as long as the version number 2.7.0 stays the same

[SolsticeSpectrum]

Found the commit!
5774cf8

The scale issue started with this commit
Now the question is if it's the line 1081 or 1329

Okay so maybe we should not use whatever is the default on macOS for other platforms
Also explains why the creator of neko which has macOS didn't experience such issue because for mac nothing essentially changed with this commit

[hajimehoshi]

• Does this issue still happen even with better scaling crgimenes/neko#27?
• Perhaps, isn't the size with 2.7 correct and too small with 2.6? I am not sure what is the correct size. From the current implementation (32x32), the size in the below image seems correct.

[SolsticeSpectrum]

@hajimehoshi The issue is not present on your for commits before 5774cf8

That commit brings it back even with your fix
As long as I stay on earlier versions, your fix works fine, there is no visible problem there

[hajimehoshi]

Does this issue still happen even with crgimenes/neko#27?

So, is the answer yes?

[SolsticeSpectrum]

@hajimehoshi yes and the exact commit which causes it is 5774cf8

[SolsticeSpectrum]

I'll try cloning that exact commit and importing it somehow to neko so I can tell you which line exactly causes it

[SolsticeSpectrum]

@hajimehoshi I don't think I can do that, I tried putting it in /usr/lib/go/src but it yells at me that stuff is missing and when I try to import it, it says stuff like /usr/lib/go/src/ebiten/colorm.go:20:2: use of internal package github.com/hajimehoshi/ebiten/v2/internal/affine not allowed

[hajimehoshi]

I don't think I can do that,

You cannot put a thrid party Go source to go/src directly.

[SolsticeSpectrum]

@hajimehoshi So what do we do? How can I check which line in 5774cf8 breaks it?

[hajimehoshi]

Have you tried #2951 (comment) ?

[hajimehoshi]

type Config struct {
	Speed int     `ini:"speed" cfg:"speed" cfgDefault:"2" cfgHelper:"The speed of the cat."`
	Scale float64 `ini:"scale" cfg:"scale" cfgDefault:"2.0" cfgHelper:"The scale of the cat."`
	Quiet bool    `ini:"quiet" cfg:"quiet" cfgDefault:"false" cfgHelper:"Disable sound."`
}

Isn't x2 the default scale by the way?

[SolsticeSpectrum]

Yes but scale 1 should work too

[hajimehoshi]

OK, so what is the current issue in your machine and expected result? I think I cannot reproduce the image sizes yet with v2.7.0 or main yet.

[SolsticeSpectrum]

@hajimehoshi Scale 1 looks like scale 2 basically and fractional values don't do anything now, they just looks like scale 2 too but only with your fix to neko. Without that fix, it's just giant pixels.

I am currently replacing the version to test the lines from the breaking commits

[SolsticeSpectrum]

@hajimehoshi Found the culprit

internal/ui/ui_glfw.go:1081

These are the lines that break the scale
Removing these lines fixes the issue even on latest commit

EDIT: Removing the lines also works for crgimenes/neko#27

[SolsticeSpectrum]

I commented on the commit and asked the contributor what does that piece of code do
5774cf8#commitcomment-140693507

[SolsticeSpectrum]

@hajimehoshi How did you make scale 1 work for you? For me it's the lines I mentioned above. I noticed that in your screenshot it looks correct. Or maybe your screen resolution is just larger.

EDIT: It's the latter, I set the screenshot to 100% percent of the size

Here it's compared to my terminal

since my resolution is significantly smaller, the cat looks bigger.

[SolsticeSpectrum]

@hajimehoshi Can you try removing the lines mentioned here #2951 (comment) on your side to see what effect it will have for you on different screen resolution? For me it fixes the issue and scale 1 is the correct scale now

Btw scale 1 should be exactly 32x32 pixels, the sprites have 32x32 pixels, it would probably look way too tiny on higher resolutions but it should stay 32x32 on 1920x1080 and bellow

[hajimehoshi]

As far as I cannot reproduce your issue in my environment, it is hard to confirm whether my fix is correct or not (especailly it is hard to tell what kind of side effects there are). I'd like to focus the issue #2952 first and then revisit this.

Can you try removing the lines mentioned here #2951 (comment) on your side to see what effect it will have for you on different screen resolution?

Nothing changes on my machine. On some machines, a small window might be visible in an unexpected way. I need to try more.

Btw scale 1 should be exactly 32x32 pixels, the sprites have 32x32 pixels, it would probably look way too tiny on higher resolutions but it should stay 32x32 on 1920x1080 and bellow

Ebitengine does automatic scaling by DeviceScaleFactor(). So in HiDPI environment, the size should be still the same.

[hajimehoshi]

@DarkReaper231 What desktop system are you using by the way? (I'm using Cinnamon)

[SolsticeSpectrum]

@hajimehoshi I have i3wm, could be some oddity with tiling wm

[hajimehoshi]

I installed i3wm but I have no idea what to do lol

[hajimehoshi]

OK I think I could reproduce your issue: the window size cannot be small, right?

[hajimehoshi]

@DarkReaper231 Thanks, I could fix this based on your investigation!

I cherry-picked the fix to 2.7 branch. I'll release v2.7.1 few days later if there is no other issue. If you want to try this earlier, you can try:

go get github.com/hajimehoshi/ebiten/v2@3136de4958eb355702c93c8e5d5ce66d39c7e0f7

Thanks!

[SolsticeSpectrum]

@hajimehoshi wow the fact that you installed i3wm just for this is wild. Never met a contributor that would go to such lengths.
Just checked it on my machine and indeed it works flawlessly, thanks!

Also maybe reporting this to i3wm wouldn't be bad idea I think if you feel like it's problem with i3wm itself.

[hajimehoshi]

Thank you for confirming the fix!

Also maybe reporting this to i3wm wouldn't be bad idea I think if you feel like it's problem with i3wm itself.

Or maybe GLFW? It is ideal if we could dive into this but wild things often happen with Linux desktops so I hope someone could do this..

[hajimehoshi]

Hmm, the fix caused a side effect: a window is unexpectedly shown when launching an app. I'll consider a better fix.

[SolsticeSpectrum]

@hajimehoshi I don't see that issue on my side. Or maybe I'm just blind

[hajimehoshi]

I confirmed this issue with Cinnamon and examples/blocks.

I came up with a better fix.

[SolsticeSpectrum]

@hajimehoshi Just wanna confirm that the better fix still works on my machine, good job!

[hajimehoshi]

@DarkReaper231 So, you tested 4d268f5 (2.7) ? Thanks!

[SolsticeSpectrum]

@hajimehoshi I tested 9c070eb just to make sure that leading commits didn't break anything

[hajimehoshi]

This commit should also be fine (though this would be different from v2.7.1). Thanks!