Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Popups (OptionButton, tooltips) placed and scaled wrong when using canvas_items stretch mode or scale factor different from 1.0 (DisplayServer regression) #54030

Open
grok-games opened this issue Oct 20, 2021 · 44 comments · May be fixed by #97745

Comments

@grok-games
Copy link

grok-games commented Oct 20, 2021


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.

popupmenu_issue1

I originally thought that this is related to my custom size of display, but it seems only "canvas_items" does this.

popupmenu_issue2

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

game-client_issue_popup_menu.zip

@grok-games grok-games changed the title PopupMenu from ItemList placed and scaled wrong (when using canvas_items mode) PopupMenu from OptionButton placed and scaled wrong (when using canvas_items mode) Oct 20, 2021
@Calinou Calinou added this to the 4.0 milestone Oct 20, 2021
@Calinou
Copy link
Member

Calinou commented Oct 20, 2021

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.

#50680 would resolve this by default, but in the meantime, you can enable Embed Subwindows in the Project Settings.

@Calinou Calinou changed the title PopupMenu from OptionButton placed and scaled wrong (when using canvas_items mode) PopupMenu from OptionButton placed and scaled wrong when using canvas_items stretch mode (DisplayServer regression) Oct 20, 2021
@grok-games
Copy link
Author

@Calinou Ok, "Embed Subwindows" places it correctly, but instead of selecting items, popup just closes, so it seems it's not a workaround.

@eleonore122
Copy link

eleonore122 commented Feb 9, 2022

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
option_button
moving above the box entirely though, does highlight the option.
option_highlighted

this behavior is consistent in both the 4.0 alpha releases

@KoBeWi
Copy link
Member

KoBeWi commented Apr 9, 2022

Looks like the regression part is fixed. The popup works correctly when you use embedded subwindows (default).

@KoBeWi KoBeWi removed the regression label Apr 9, 2022
@Calinou
Copy link
Member

Calinou commented Apr 9, 2022

I tested the behavior in godotengine/godot-demo-projects#713 with commit 83d2673, and popup drawing is still blurry when using a larger-than-default window size with the canvas_items stretch mode:

image

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.)

@YuriSizov
Copy link
Contributor

cc @Sauermann Is this something you might've fixed recently?

@Sauermann
Copy link
Contributor

@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.

@Calinou
Copy link
Member

Calinou commented Jun 1, 2023

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.

@michaldev
Copy link

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.

Zrzut ekranu 2023-06-8 o 13 31 20

@Koyper
Copy link
Contributor

Koyper commented Jan 4, 2024

I've updated #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.

@scgm0
Copy link
Contributor

scgm0 commented Apr 18, 2024

#86553 has been merged. Has the problem of blurred fonts in embedded sub-windows been resolved?

@Calinou
Copy link
Member

Calinou commented Apr 18, 2024

#86553 has been merged. Has the problem of blurred fonts in embedded sub-windows been resolved?

This issue doesn't appear to be fixed yet as of 4.3.dev 2efbc6b (tested on https://github.com/godotengine/godot-demo-projects/tree/master/3d/graphics_settings):

As the PR's description says:

This will not relate directly to a fix for the blurry subwindows issue, but might help with the eventual solution for that.

Default project window size

image

Fullscreen in canvas_items stretch mode (3840×2160)

image

@mgc8
Copy link

mgc8 commented Apr 24, 2024

#86553 has been merged. Has the problem of blurred fonts in embedded sub-windows been resolved?

I see no change on my project either (same as above). Might improve specific situations, but not the one I hit (pop-up windows within the app). I can't switch them to non-embedded, because then on desktop OSs they appear as separate windows which is not desirable at all.

@Emppu45
Copy link

Emppu45 commented May 1, 2024

I'm hoping to see this get fixed very soon. Games depending on pixel art and low viewport resolutions greatly suffer from this, causing text to become unreadable. Example below with viewport size of 640x360 and PopupMenu font size at 8px.
game_menu

@Koyper
Copy link
Contributor

Koyper commented May 1, 2024

Now that non-embedded popups/tooltip scaling is fixed, it might be worth experimenting with the Project embed subwindows disabled. For popup panels, you can hide the title bar and use your own code for clamping the window movement to remain inside the main window so that it acts pretty much like an embedded popup.

@gokiburikin
Copy link

I had a similar issue when using my own pixel font. The root problem in my case being that Windows get their own viewport and default canvas item filters aren't inherited.

I fixed this issue by manually setting the default filtering for each OptionButton like this:

$OptionButton.get_popup().get_viewport().canvas_item_default_texture_filter = 0

You can also extend the OptionButton control to one that copies the filtering of the parent node's viewport like this:

extends OptionButton

func _ready() -> void:
	get_popup().get_viewport().canvas_item_default_texture_filter = get_viewport().canvas_item_default_texture_filter

Before: Godot_v4 3-dev6_win64_2024-05-03_14-50-12 After: Godot_v4 3-dev6_win64_2024-05-03_14-50-36

I don't think this is the solution most people in here need, but it might be useful to other people like me who ended up here looking for answers.

@Emppu45
Copy link

Emppu45 commented May 4, 2024

Disabling project embed subwindows fixes the issue. As @Koyper said, I too can recommend experimenting with it.

Seems like embedded subwindows is still broken.

@Koyper
Copy link
Contributor

Koyper commented May 4, 2024

Disabling project embed subwindows fixes the issue. As @Koyper said, I too can recommend experimenting with it.

Seems like embedded subwindows is still broken.

The scaling fix for non-embedded subwindows is in 4.3dev6 or later.

@kidinashell
Copy link
Contributor

Is it very naive to ask, how the editor itself handles UI scaling then? Doesn't the editor use the same settings for scaling its UI? Because it seems to work fine for the editor in the cases of OptionButton Popups for example (as well as all the other Controls that spawn new Viewports/Windows).

@Calinou
Copy link
Member

Calinou commented May 16, 2024

Is it very naive to ask, how the editor itself handles UI scaling then?

The editor regenerates its theme with the specified scale factor and font size from the Editor Settings. It does not use the content scale factor functionality of Godot – it always uses the disabled stretch mode with a scale factor of 1.0.

This approach is mostly used for historical reasons. Note that #86022 overhauls how editor scaling is performed.

@akien-mga akien-mga changed the title PopupMenu from OptionButton placed and scaled wrong when using canvas_items stretch mode or scale factor different from 1.0 (DisplayServer regression) Popups (OptionButton, tooltips) placed and scaled wrong when using canvas_items stretch mode or scale factor different from 1.0 (DisplayServer regression) Sep 3, 2024
@MagiusCHE
Copy link

Seems i have the same problem. I managed to solve it by create a second instance of the tooltip and hide the original one.
Here how they appear. (bottom = original tooltip instance, top the second custom instance)
image

Here the code i've used:

func _make_custom_tooltip(for_text):
    var tooltip = instantiate(for_text)
    tooltip.connect("tree_entered", _on_tooltip_entered.bind(tooltip))
    tooltip.connect("tree_exiting", _on_tooltip_exiting.bind(tooltip))

    return tooltip

func _on_tooltip_exiting(source_tooltip):
    if cloned:
        cloned.queue_free()
        cloned = null

var cloned = null
func _on_tooltip_entered(source_tooltip):
    var tooltip = instantiate(source_tooltip.get_node("Label").text)
    #source_tooltip.hide()
    cloned = tooltip
    TheApp.active_scene.add_child(tooltip)
    # Set to actual mouse global position
    tooltip.position = get_viewport().get_mouse_position() + Vector2(10, -60)

func instantiate(for_text: String):
    var tooltip = preload("res://cards/card_tool_tip.tscn").instantiate()
    tooltip.get_node("Label").text = for_text
    return tooltip

@scgm0
Copy link
Contributor

scgm0 commented Sep 30, 2024

Is there no solution to the blur problem yet? godot is now 4.3, 4.4 has also released dev2, and dev3 will be released soon. This problem really affects the experience. . .

@DinoMC
Copy link

DinoMC commented Oct 1, 2024

Is there a workaround in 4.3 for Dialogs (AcceptDialog, ConfirmationDialog, ...) ?

I want to release a demo of my game but the Dialogs' text looks extremely blurry. I don't care if I have to add code to every single dialog one by one to fix it, but I don't know how.

I tried gokiburikin's fix above and it makes the text look less blurry, but still wrong (some kind of scaling issue with letters having uneven sizes in the same word). Any idea why?

@scgm0 scgm0 linked a pull request Oct 2, 2024 that will close this issue
@scgm0
Copy link
Contributor

scgm0 commented Oct 2, 2024

Is there a workaround in 4.3 for Dialogs (AcceptDialog, ConfirmationDialog, ...) ?

I want to release a demo of my game but the Dialogs' text looks extremely blurry. I don't care if I have to add code to every single dialog one by one to fix it, but I don't know how.

I tried gokiburikin's fix above and it makes the text look less blurry, but still wrong (some kind of scaling issue with letters having uneven sizes in the same word). Any idea why?

try #97745 ?
or

	root.size_changed.connect(func():
		RenderingServer.viewport_set_global_canvas_transform(window.get_viewport_rid(), window.global_canvas_transform * window.get_screen_transform().get_scale().x);
		RenderingServer.viewport_set_size(window.get_viewport_rid(), window.size.x * window.get_screen_transform().get_scale().x, window.size.y * window.get_screen_transform().get_scale().y);
		pass
	)

@mgc8
Copy link

mgc8 commented Oct 2, 2024

@scgm0 I can confirm that #97745 worked for my projects, all embedded windows now look ice-sharp! So far I'm seeing no ill effects, but of course cannot speak for everyone out there. I hope the change gets included, as it would be a great solution for this long-standing problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.