Skip to content
This repository has been archived by the owner on Feb 17, 2022. It is now read-only.

Incorrect canvas render size when rendering with framebuffers on a HiDPI screen #109

Open
MCJack123 opened this issue Mar 25, 2020 · 1 comment · May be fixed by #116
Open

Incorrect canvas render size when rendering with framebuffers on a HiDPI screen #109

MCJack123 opened this issue Mar 25, 2020 · 1 comment · May be fixed by #116

Comments

@MCJack123
Copy link

I'm working on porting a C++ program that uses SDL2 to Emscripten. I have gotten most things to work, but I'm having trouble making HiDPI support work. This is what the program looks like on desktop with HiDPI:
Screen Shot 2020-03-24 at 11 32 40 PM

This is the exact same code running in an Emscripten environment using this SDL2 port, on the same HiDPI screen:
Screen Shot 2020-03-24 at 11 32 51 PM

Notice how the entire screen is rendered only in the top left corner of the screen, and that everything is 2x smaller. If I change the code to render the screen at 2x resolution, it looks like this:
Screen Shot 2020-03-24 at 11 34 19 PM

The text is at the correct size, but only a quarter of the screen is showing up. If I make the created window 2x larger, it makes the canvas much larger than the border:
Screen Shot 2020-03-25 at 12 05 34 AM

For reference, here's what it looks like without HiDPI enabled:
Screen Shot 2020-03-24 at 11 42 14 PM

I looked at the source a bit and found that:

  1. The size of the image data is 4x smaller than it would be with the full size (in this case, it's 620x350 pixels long instead of 1240x700 pixels long). This could be fixed by applying data->pixel_ratio to the width and height, but I don't believe this is a portable solution since the normal SDL behavior doesn't require the application to do 2x rendering itself. (?)
  2. The actual image data is not scaled up to 2x size anywhere in Emscripten_UpdateWindowFramebuffer, which under normal circumstances I would expect, but due to the way SDL2 seems to handle HiDPI (at least from my experience) the image should be integer scaled up to the correct resolution.

Note that I don't really understand how HiDPI works with normal SDL (I just messed with code until I got a result), so I may be wrong on how to handle this; but I know for sure that more than just a quarter of the canvas should be accessible with HiDPI.

@Daft-Freak
Copy link
Member

Daft-Freak commented Mar 25, 2020

Hmm, it looks like most of the other backends with HiDPI support don't have framebuffer support and fall back to using a renderer internally, which handles the scale automatically. It looks like we would need to scale in Emscripten_UpdateFramebuffer to handle this correctly.

As a workaround, you can use SDL_SetHint(SDL_HINT_FRAMEBUFFER_ACCELERATION, "1"); before you call SDL_Init to force going through the renderer.

EDIT: Hmm, since the framebuffer seems to always be non-HiDPI you could just disable HiDPI and use CSS image-rendering on the canvas to control the scaling...

MCJack123 added a commit to MCJack123/craftos2 that referenced this issue Mar 26, 2020
Due to a bug in SDL2 (emscripten-ports/SDL2#109), HiDPI mode forces the
canvas to be larger on HiDPI monitors. To work around this, use the
following CSS rules on the canvas:
```
@media (min-resolution: 144dpi) and (max-resolution: 240dpi) {
    canvas.emscripten {
        clip-path: polygon(0% 0%, 0% 50%, 50% 50%, 50% 0%);
        margin-left: 620px;
        margin-top: 350px;
    }
}

@media (min-resolution: 240dpi) and (max-resolution: 336dpi) {
    canvas.emscripten {
        clip-path: polygon(0% 0%, 0% 33.33333333%, 33.33333333% 33.33333333%, 33.33333333% 0%);
        margin-left: 1240px;
        margin-top: 700px;
    }
}
```
HiDPI can be disabled by adding `-DNO_EMSCRIPTEN_HIDPI` to CPPFLAGS.
@Daft-Freak Daft-Freak linked a pull request Apr 15, 2020 that will close this issue
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants