godot
godot copied to clipboard
Popups (OptionButton, tooltips) placed and scaled wrong when using `canvas_items` stretch mode or scale factor different from `1.0` (DisplayServer regression)
Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.
Godot version
4.0-dev.20211004_win64
System information
Windows 10
Issue description
When using OptionButton and choosing canvas_items mode in Project Settings->Display, popup of OptionButton is placed and scaled wrong (fonts too). When using "disabled" mode it is placed correctly.
I originally thought that this is related to my custom size of display, but it seems only "canvas_items" does this.
I've added project, so you can test. but it's pretty obvious, I have no scaling or complex settings on nodes.
Steps to reproduce
Set canvas_items mode and use PopupButton.
Minimal reproduction project
This is because multiple windows are now used by default (this applies to PopupMenus so they can extend outside the project window). However, child windows are currently not scaled with the scale factor automatically determined by the canvas_items
stretch mode.
https://github.com/godotengine/godot/pull/50680 would resolve this by default, but in the meantime, you can enable Embed Subwindows in the Project Settings.
@Calinou Ok, "Embed Subwindows" places it correctly, but instead of selecting items, popup just closes, so it seems it's not a workaround.
I've encountered the same thing, and is seems that the clickable area for the subwindow is placed in a different spot than the subwindow itself.
here you can see the dropdown menu, hovering near the option doesn't highlight anything
moving above the box entirely though, does highlight the option.
this behavior is consistent in both the 4.0 alpha releases
Looks like the regression part is fixed. The popup works correctly when you use embedded subwindows (default).
I tested the behavior in https://github.com/godotengine/godot-demo-projects/pull/713 with commit 83d267377, and popup drawing is still blurry when using a larger-than-default window size with the canvas_items
stretch mode:
The icon drawing will always be blurry as it's not re-rasterized for higher window sizes, but the StyleBox and font drawing could be made sharp as they would be in 3.x
.
(Embed Subwindows is enabled here.)
cc @Sauermann Is this something you might've fixed recently?
@YuriSizov
Looks like the regression part is fixed. The popup works correctly when you use embedded subwindows (default).
I can confirm that this problem is solved.
popup drawing is still blurry when using a larger-than-default window size with the canvas_items stretch mode
I am not yet familiar with the rendering-functionality to properly investigate this second issue.
PS: This affects the entire popup rendering, not just font oversampling, so MSDF fonts and polygon-based drawing (including StyleBoxFlat) remain blurry at higher scale factors.
Is there a chance for improvement in Godot 4.1 (or even 4.0)? In my opinion, this is a bug that prevents the creation of many games. Take a look at how it looks in practice during font rendering.
@michaldev This is an unrelated issue, and isn't a bug. Pixel art fonts must be rendered at an integer multiple of the size they were designed for. Also, subpixel positioning must be disabled in the font's import options in the Import dock on pixel art fonts.
For instance, if you use a pixel art font that is meant to be displayed at a size of 12 pixels, this means that its size in practice (taking into account the scale factor) must be 12, 24, 36, 48, … See also https://github.com/godotengine/godot-proposals/issues/1666. Beware that some fonts will specify their design size in points (pt), which is a different unit from pixels.
I understand, but this problem only occurs with pop-ups (with canvas_items and stretch mode). Look, I have prepared an example (with project in zip). https://github.com/godotengine/godot/issues/77873
I understand, but this problem only occurs with pop-ups (with canvas_items and stretch mode). > Look, I have prepared an example. https://github.com/godotengine/godot/issues/77873
I can notice uneven pixel scaling in the background:
If you were using integer pixel scaling, each cross would be exactly aligned with a pixel's corner. This is not the case in the above screenshot (taken using GIMP with a grid size of 1 pixel).
Ensure you have integer pixel scaling going on, then try again. You can read more about the underlying issue here.
The example you provided (with zombies) I set a very unusual parameter "scale" for the graphics on the cards, which is likely why the pixel count doesn't align with the "grid". The example I mentioned in the above-mentioned issue completely lacks graphics and only showcases the problem with fonts. Even when I enter twice the original font size and choose the 'nearest' filter, the issue remains.
Exactly the same text labels - with the same font size and texture filtering - work fine throughout the game, except for popups.
Edit: OK now I understand. So should I use a higher game resolution to avoid such issues?
I see a number of different bugs have been closed to point to this one instead. However, the reference to canvas_items
in the title seems to be limiting what is otherwise a more general issue. We get the same ugly, blurred text in windows, tool-tips and pop-ups despite not using that option, only for having Scale
enabled with a value larger than "1":
And the result:
If this is all the same problem, perhaps it bears making sure any implemented fix looks further than just the specific case of canvas_items
?
However, the reference to
canvas_items
in the title seems to be limiting what is otherwise a more general issue. We get the same ugly, blurred text in windows, tool-tips and pop-ups despite not using that option, only for having Scale enabled with a value larger than "1":
The underlying problem is the same – it's an issue of rendering always being performed at the base scale factor. I've edited the issue's title accordingly.
Possibly add "tooltip" or "blurry tooltip" and "hiDPI" keywords to title to make it easier to find this main issue? (Unless there is another open issue I couldn't find).
Can the milestone to fix the blurry rendering be achieved in 4.2? Is the specific fix required been identified? Thanks!
Possibly add "tooltip" or "blurry tooltip" and "hiDPI" keywords to title to make it easier to find this main issue? (Unless there is another open issue I couldn't find).
Since you wrote these words, they can now be used to find this issue 🙂
Can the milestone to fix the blurry rendering be achieved in 4.2? Is the specific fix required been identified? Thanks!
We don't know how to fix this, so we can't give an ETA.
I realize the following idea is reversing a no doubt well-deliberated decision to move PopupMenu
under viewports, but a new ResizableWindow
class designed to mirror the applicable theme and properties of Window
and then made to be inherited by all the PopupMenu
controls would offer a definitive fix. ResizableWindow
would inherit PanelContainer
and be given grab edges and corners and be gui-draggable. Resizing/dragging can be enabled/disabled.
Can the milestone to fix the blurry rendering be achieved in 4.2? Is the specific fix required been identified? Thanks!
We don't know how to fix this, so we can't give an ETA.
Is this because nobody had time to properly look into it, or because it's such a baffling issue that no developer knows how to approach it? Is there a starting point we could use to start tackling this? I'd like to help debugging the issue, but don't have enough familiarity with the code to know where to begin... Some pointers would help a lot!
Here's a tangentially related question: with the ability of Godot 4's DisplayServer
and TextServer
to manage window scaling transparently, the editor itself is still relying on EDSCALE
throughout to handle different window scale factors, whereas it could theoretically be setting content_scale_factor
instead - I'm presuming it would have been extraordinary to have done that simultaneously with the new servers?
I was investigating why the editor windows that can "float" like the script window, are NOT blurry on a Retina display.
This has probably already been discussed, but a non-embedded Window
that is scaled to 2.0 is not blurry, but if that same window is put inside a SubViewport
it will then be blurry. So necessary rendering code is being skipped when the embed flag is set.
Can confirm that this is still an issue in 4.1 This is not an issue in ver 3, however.
I think I have the same issue.
I set the scale using get_window().content_scale_factor
, to 3.0
in this case, but PopupMenu
and OptionMenu
stay at 1.0
.
[Godot v4.2.dev3 - macOS 13.5.0 - GLES3 (Compatibility) - Apple M1 - Apple M1 (8 Threads)]
@KoB-Kirito Can you please upload a minimal reproduction project for your issue? This would help identifying the exact cause for this problem.
@Sauermann Content Scale Factor.zip
display/window/subwindows/embed_subwindows
has to be disabled, so new windows are spawned. Other than that I didn't change anything.
@KoB-Kirito thanks, what you describe is tracked in #69171 and #69749
Ah okay.
I noticed that I can fix it by getting the popup and connecting to it's about to show signal and applying the factor there too, also have to scale window size then. A lot of work though if you have a lot of popup creating things.
@Sauermann I tried to implement that workaround fix, but it yields another problem: The selection with mouse behaves as if the popup is not scaled. It's quite weird and hard to explain. Reproduction: Content Scale Factor.zip
@KoB-Kirito I had a look at your project file with the GDScript-fix and I noticed an additional problem with it, namely that the popups are much wider than they are supposed to be: They should be as wide as the button.
I've updated https://github.com/godotengine/godot/pull/86553 so all the changes are in one place. When merged, some projects can get around the blurry embedded subwindows issue by switching to non-embedded subwindows, which now should scale to match the main viewport content scale factor, and will not be blurry and look crisp on HiDPI (Retina) displays.
#86553 has been merged. Has the problem of blurred fonts in embedded sub-windows been resolved?