8000 Backends: Glfw, SDL2: ImplXXXGetContentScale shall return 1 on emscripten / apple / android by pthom · Pull Request #8742 · ocornut/imgui · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Backends: Glfw, SDL2: ImplXXXGetContentScale shall return 1 on emscripten / apple / android #8742

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Backends: Glfw, SDL2: ImplXXXGetContentScale shall return 1 on emscripten / apple / android #8742

wants to merge 2 commits into from

Conversation

pthom
Copy link
Contributor
@pthom pthom commented Jun 27, 2025

This is a fix related to #8733

We can divide platforms into two cases based on how they report screen geometry:

Case 1: Platforms which report screen size in "physical pixels": Windows (for "Dpi aware" apps), Linux (with Wayland)

Case 2: Platforms which report screen size in "density-independent pixels": macOS, iOS, Android, emscripten

As a consequence, there are two important things we need to know:

  • FramebufferScale: The scaling factor FrameBufferSize / ScreenSize

    • In case 1, the framebuffer size is equal to the screen size and DisplayFramebufferScale=1.
    • In case 2, the framebuffer size is equal to the screen size multiplied by a factor, for example DisplayFramebufferScale=2.

  • ContentScale The scaling factor for the content that we will display

    • In case 1, the content scale will often need to be > 1 (e.g., 2), because we will need to display bigger elements so that they show with a correct physical size on the screen.
    • In case 2, the content scale is equal to 1

This commit fixes ContentScale for platforms in case 2.

@pthom pthom mentioned this pull request Jun 27, 2025
Open
@ocornut
Copy link
Owner
ocornut commented Jun 27, 2025

Thanks for the PR.

There is a printf() left.

Is the value of io.DisplayFramebufferScale & returned by Platform_GetWindowFramebufferScale then correct on Emscripten on all 3 backends?

@pthom
Backends: Glfw, SDL2: ImplXXXGetContentScale shall return 1 on emscri…
fe2b85d 
…pten / apple / android

This is a fix related to ocornut#8733

We can divide platforms into two cases based on how they report screen geometry:

    Case 1: Platforms which report screen size in "physical pixels": Windows (for "Dpi aware" apps), Linux (with Wayland)
    Case 2: Platforms which report screen size in "density-independent pixels": macOS, iOS, Android, emscripten

As a consequence, there are two important things we need to know:

    FramebufferScale: The scaling factor FrameBufferSize / ScreenSize
        In case 1, the framebuffer size is equal to the screen size and DisplayFramebufferScale=1.
        In case 2, the framebuffer size is equal to the screen size multiplied by a factor, for example DisplayFramebufferScale=2.
    ContentScale The scaling factor for the content that we will display
        In case 1, the content scale will often need to be > 1 (e.g., 2), because we will need to display bigger elements so that they show with a correct physical size on the screen.
        In case 2, the content scale is equal to 1

This commit fixes ContentScale for platforms in case 2.
@pthom pthom force-pushed the fix_content_scale branch from a0dcc29 to fe2b85d Compare June 27, 2025 13:58
@pthom
Copy link
Contributor Author
pthom commented Jun 27, 2025

There is a printf() left.

fixed, sorry

@pthom
Copy link
Contributor Author
pthom commented Jun 27, 2025

Is the value of io.DisplayFramebufferScale & returned by Platform_GetWindowFramebufferScale then correct on Emscripten on all 3 backends?

  • example_sdl2_opengl3:

    • ContentScale is equal to 1 (OK)
    • DisplayFrameBufferScale is equal to 2 on a retina screen, and varies according to browser zoom: OK

  • example_glfw_opengl3 and example_glfw_webgpu:

    • ContentScale is equal to 1 (OK)
    • DisplayFrameBufferScale is now correctly handled (and depends on the browser zoom level): OK

This was done using the flag --use-port=contrib.glfw3 instead of -s USE_GLFW=3

This way, we use emscripten-glfw, which offers a better support for HighDPI.

Note: an alternative (but faulty) solution would have been to stick to -sUSE_GLFW=3 and then modify main.cpp by adding :

#ifdef __EMSCRIPTEN__
glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE);
#endif

This solution works partially (the FrameBufferScale is passed). However, it will create a window with a bad size as soon as the browser zoom level is not 100%. It is therefore not applicable.

ypujante
ypujante reviewed Jun 27, 2025
View reviewed changes
examples/example_glfw_wgpu/Makefile.emscripten
@@ -32,8 +32,9 @@ EMS =
##---------------------------------------------------------------------

# ("EMS" options gets added to both CPPFLAGS and LDFLAGS, whereas some options are for linker only)
EMS += -s DISABLE_EXCEPTION_CATCHING=1
LDFLAGS += -s USE_GLFW=3 -s USE_WEBGPU=1
# Note: For glfw, we use emscripten-glfw port (contrib.glfw3) instead of (-s USE_GLFW=3) to get a better support for High DPI displays.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just an FYI, emscripten-glfw offers much more than better support for Hi DPI, like for example gamepad support, copy/paste, workaround for meta key (broken with -s USE_GLFW=3), etc...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ypujante ypujante ypujante left review comments

Assignees
No one assigned
Labels
backends dpi
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@pthom @ocornut @ypujante
0