Can't scale canvas with CSS without it changing the canvas Width and Height properties

[michaelfiber]

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.70 (b53978ee3f540dc74761eba127aa7f1b8761a125)
clang version 20.0.0git (https:/github.com/llvm/llvm-project f52b89561f2d929c0c6f37fd818229fbcad3b26c)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/michael/dev/raylib-test/emsdk/emsdk-main/upstream/bin

Starting with version 3.1.51 the width and height properties of a canvas as overridden if you use CSS to change the size of the canvas. How do we maintain the original way of doing it where you can use CSS to change the canvas.style.width and canvas.style.height without it overriding the canvas.width and canvas.height?

There is an issue open on the raylib project related to this: raysan5/raylib#4464 - but it doesn't seem like an issue with raylib itself.

The goal is to continue to allow emscripten programs compiled with GLFW=3 to be scaled up to fill a containing element with object-fit: cover or something similar so that you could, for instance, use CSS to allow an itch.io game to go fullscreen while the game itself remains a fixed resolution.

[sbc100]

Can you confirm this was broken between 3.1.50 and 3.1.51? Could you perhaps bisect to see exactly which emscripten change broke this: https://emscripten.org/docs/contributing/developers_guide.html#bisecting

[sbc100]

I see only 3 changes to the glfw between 3.1.50 and 3.1.51 so I suppose the culprit is likely one these:

$ git l 3.1.50..3.1.51  src/library_glfw.js
05821a3ed Leverage coalescing operators. NFC (#20531) 11 months ago [Ingvar Stepanyan]
c26fc388e Add Hi DPI Support for GLFW (#20584) 11 months ago [Yan Pujante]
95591bcfb Use `let` for loop variable instead of IIFEs. NFC (#20823) 11 months ago [Sam Clegg]
7d639f7a6 Fix glfw3 default hints being modified (#20770) 11 months ago [Yan Pujante]
b3b0f2794 Fix touch input handling for glfw. (#20805) 11 months ago [Ruben]

My guess is that it would be #20584. @ypujante WDYT?

[curiousdannii]

I had a similar issue and had to overwrite emscripten_set_canvas_element_size to fix things in my project, though I'm not using (I think) GLFW, only SDL2. It doesn't look like it's been changed recently though.

[deathbeam]

I was testing this as well and yes the issue is between 3.1.50 and 3.1.51 (not reproducable on 3.1.50 and lower, reproducable after 3.1.51). I havent tried specific commits, was just using emsdk and checkouting tags + using emsdk install/activate for tags. When debugging in raylib disc we suspect that the issue is indeed #20584, specifically this section:

https://github.com/emscripten-core/emscripten/pull/20584/files#diff-efefa0c433583bf964817ede50dac6afac9e3ff5686e3af838993fb5f1717117R1244

[ypujante]

The changes in PR #20584 were made to allow support for 4k/Hi DPI. The code in library_glfw.js that @deathbeam links to is the following:

      const wNativeScaled = Math.floor(wNative * scale);
      const hNativeScaled = Math.floor(hNative * scale);
      if (canvas.width  != wNativeScaled) canvas.width  = wNativeScaled;
      if (canvas.height != hNativeScaled) canvas.height = hNativeScaled;
      if (typeof canvas.style != 'undefined') {
        if (wNativeScaled != wNative || hNativeScaled != hNative) {
          canvas.style.setProperty( "width", wNative + "px", "important");
          canvas.style.setProperty("height", hNative + "px", "important");
        } else {
          canvas.style.removeProperty( "width");
          canvas.style.removeProperty("height");
        }
      }

and it overrides the code in library_browser.js which is:

        if (canvas.width  != wNative) canvas.width  = wNative;
        if (canvas.height != hNative) canvas.height = hNative;
        if (typeof canvas.style != 'undefined') {
          if (w != wNative || h != hNative) {
            canvas.style.setProperty( "width", w + "px", "important");
            canvas.style.setProperty("height", h + "px", "important");
          } else {
            canvas.style.removeProperty( "width");
            canvas.style.removeProperty("height");
          }
        }

and which was used prior to this PR.

As you can see, if the scale is 1.0, then the 2 code paths are identical.

So my question is, are you trying to make raylib work with 4k/Hi DPI?

[deathbeam]

HDPI is disabled, as mentioned in the main post and linked issue, the issue is that it breaks when you set for example width: 100% css style on canvas.emscripten to scale it and the canvas dimensions end up being incorrect, and this worked before 3.1.51. Example of styling:

      canvas.emscripten {
        border: 0px none;
        background: black;
        width: 100%;
      }

[ypujante]

@deathbeam can you provide a working minimal example so that I can try to reproduce the issue, ideally an example using glfw directly and not raylib?

Thank you

[deathbeam]

@deathbeam can you provide a working minimal example so that I can try to reproduce the issue, ideally an example using glfw directly and not raylib?

Thank you

Sadly only thing I can provide is reproduction step for raylib, maybe @michaelfiber or someone else could provide glfw one, but here is raylib one anyway just in case:

emsdk setup:

git clone https://github.com/emscripten-core/emsdk
cd emsdk
git checkout 3.1.51
./emsdk install 3.1.51 && ./emsdk activate 3.1.51
source emsdk_env.sh

git clone https://github.com/raysan5/raylib
cd raylib/src
make PLATFORM=PLATFORM_WEB -B
cd ../examples
# Because of change in 3.1.51 add -sGL_ENABLE_GET_PROC_ADDRESS on line 275 in Makefile.web
# This is not required on newer releases so i guess it was made no required sometime after
# This also fails on one of the examples but the testing one should build before that
make PLATFORM=PLATFORM_WEB -B
emrun --port 8080 core/core_2d_camera_mouse_zoom.html

the shell being used in raylib example is in src/shell.html, the testing example is in examples/core/core_2d_camera_mouse_zoom.c.

If you retry this same steps on 3.1.50 the canvas is properly scaled to full screen width, on 3.1.51 and later its stuck in bottom-left corner at first and also input is not matching the canvas either. Works fine when width: 100% is removed from the shell.html (line 82) but with undesired behaviour (scaling no longer possible).

[ypujante]

Given my prior experience with raylib, I must admit I am not super motivated in helping debugging raylib.

I will gladly take a look at the issue you refer to (which might be raylib not using GLFW properly) if somebody provides me with a self contained, pure GLFW minimal example.

For your convenience, here is a very minimal GFLW piece of cpp code that I have written (adapted from an example for my emscripten-glfw library):

#include <emscripten/emscripten.h>
#include <emscripten/html5.h>
#include <GLFW/GLFW3.h>
#include <cstdio>
#include <cmath>

void consoleErrorHandler(int iErrorCode, char const *iErrorMessage)
{
  printf("glfwError: %d | %s\n", iErrorCode, iErrorMessage);
}

//! jsRenderFrame: for the sake of this example, uses the canvas2D api to change the color of the screen / display a message
EM_JS(void, jsRenderFrame, (GLFWwindow *glfwWindow, int w, int h, int fw, int fh, double mx, double my, int color, bool isFullscreen), {
  const ctx = Module.canvas.getContext('2d');
  ctx.fillStyle = `rgb(${color}, ${color}, ${color})`;
  ctx.fillRect(0, 0, fw, fh); // using framebuffer width/height
  const text = `${w}x${h} | ${mx}x${my}`;
  ctx.font = '15px monospace';
  ctx.fillStyle = `rgb(${255 - color}, 0, 0)`;
  ctx.fillText(text, 10 + color, 20 + color);
})

//! Called for each frame
void renderFrame(GLFWwindow *iWindow)
{
  static int frameCount = 0;

  // poll events
  glfwPollEvents();

  int w,h; glfwGetWindowSize(iWindow, &w, &h);
  int fw,fh; glfwGetFramebufferSize(iWindow, &fw, &fh);
  double mx,my; glfwGetCursorPos(iWindow, &mx, &my);
  auto color = 127.0f + 127.0f * std::sin((float) frameCount++ / 120.f);
  jsRenderFrame(iWindow, w, h, fw, fh, mx, my, (int) color, false);
}

//! The main loop (called by emscripten for each frame)
void main_loop(void *iUserData)
{
  if(auto window = reinterpret_cast<GLFWwindow *>(iUserData); !glfwWindowShouldClose(window))
  {
    // not done => renderFrame
    renderFrame(window);
  }
  else
  {
    // done => terminating
    glfwTerminate();
    emscripten_cancel_main_loop();
  }
}

//! main
int main()
{
  // set a callback for errors otherwise if there is a problem, we won't know
  glfwSetErrorCallback(consoleErrorHandler);

  // print the version on the console
  printf("%s\n", glfwGetVersionString());

  // initialize the library
  if(!glfwInit())
    return -1;

  // no OpenGL (use canvas2D)
  glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);

  // create the only window
  auto window = glfwCreateWindow(600, 400, "Emscripten #22847", nullptr, nullptr);
  if(!window)
    return -1;

  // tell emscripten to use "main_loop" as the main loop (window is user data)
  emscripten_set_main_loop_arg(main_loop, window, 0, GLFW_FALSE);
}

What I need is the shell.html file (and/or changes to the cpp code) that would demonstrate the issue and what your expectations are.

[raysan5]

Hi! I created two videos illustrating the issue:

Environment:

• MSI Laptop, with a 1920x1080 display
• Windows 10 64bit (22H2)
• Google Chrome Version 130.0.6723.92 (Official Build) (64-bit)
• raylib 5.5-dev (master-branch)

Example compiled with emsdk 3.1.50 (expected behaviour)

Framebuffer is 800x450, canvas has CSS property width: 100%. The canvas fit the 100% of browser width space when browser resized but the canvas framebuffer it's 800x450 and the input is reported considering that framebuffer size, independent of the browser window size.

canvas_scale100_emsdk3.1.50.mp4

Example compiled with emsdk 3.1.51

First time the page is loaded, the canvas is scaled to 100% the browser size but the framebuffer (800x450) is placed in the lower-left corner of the canvas. Mouse position is relative to canvas position/size, not framebuffer. When browser is resized, the canvas is proportionally resized, including the contained framebuffer and also its relative mouse input.

canvas_scale100_emsdk3.1.51.mp4

NOTE 1: If width:100% is disabled for the canvas, the canvas (and its content) does not resize with browser, the framebuffer get just cut.

NOTE 2: It has been tested on a 1920x1080 monitor (no High-DPI) and the HighDPI flag is not enabled on GLFW.

NOTE 3: All web platform code is contained in raylib/src/platforms/platform_web.c.

Please, let me know if you need further information.

[ypujante]

@raysan5 Thank you for posting the videos / showing the problem you are seeing with raylib.

As I mentioned, personally, I need a reproducible example that is not relying on raylib and using GLFW directly. I already gave you 99% of the code...

If somebody else from the Emscripten team wants to debug raylib, of course they can do that, but I won't.

[raysan5]

@ypujante I don't understand your adversion to raylib project, but please note that this is a breaking change that happened after 10 years of a expected working behaviour and affects thousands of raylib users, potentially way more users than plain GLFW-on-web users. Not to mention the hundreds of raylib web projects that you can find for example on itchio.

I think it deserves some consideration.

[michaelfiber]

Given my prior experience with raylib, I must admit I am not super motivated in helping debugging raylib.

I will gladly take a look at the issue you refer to (which might be raylib not using GLFW properly) if somebody provides me with a self contained, pure GLFW minimal example.

For your convenience, here is a very minimal GFLW piece of cpp code that I have written (adapted from an example for my emscripten-glfw library):

#include <emscripten/emscripten.h>
#include <emscripten/html5.h>
#include <GLFW/GLFW3.h>
#include <cstdio>
#include <cmath>

void consoleErrorHandler(int iErrorCode, char const *iErrorMessage)
{
  printf("glfwError: %d | %s\n", iErrorCode, iErrorMessage);
}

//! jsRenderFrame: for the sake of this example, uses the canvas2D api to change the color of the screen / display a message
EM_JS(void, jsRenderFrame, (GLFWwindow *glfwWindow, int w, int h, int fw, int fh, double mx, double my, int color, bool isFullscreen), {
  const ctx = Module.canvas.getContext('2d');
  ctx.fillStyle = `rgb(${color}, ${color}, ${color})`;
  ctx.fillRect(0, 0, fw, fh); // using framebuffer width/height
  const text = `${w}x${h} | ${mx}x${my}`;
  ctx.font = '15px monospace';
  ctx.fillStyle = `rgb(${255 - color}, 0, 0)`;
  ctx.fillText(text, 10 + color, 20 + color);
})

//! Called for each frame
void renderFrame(GLFWwindow *iWindow)
{
  static int frameCount = 0;

  // poll events
  glfwPollEvents();

  int w,h; glfwGetWindowSize(iWindow, &w, &h);
  int fw,fh; glfwGetFramebufferSize(iWindow, &fw, &fh);
  double mx,my; glfwGetCursorPos(iWindow, &mx, &my);
  auto color = 127.0f + 127.0f * std::sin((float) frameCount++ / 120.f);
  jsRenderFrame(iWindow, w, h, fw, fh, mx, my, (int) color, false);
}

//! The main loop (called by emscripten for each frame)
void main_loop(void *iUserData)
{
  if(auto window = reinterpret_cast<GLFWwindow *>(iUserData); !glfwWindowShouldClose(window))
  {
    // not done => renderFrame
    renderFrame(window);
  }
  else
  {
    // done => terminating
    glfwTerminate();
    emscripten_cancel_main_loop();
  }
}

//! main
int main()
{
  // set a callback for errors otherwise if there is a problem, we won't know
  glfwSetErrorCallback(consoleErrorHandler);

  // print the version on the console
  printf("%s\n", glfwGetVersionString());

  // initialize the library
  if(!glfwInit())
    return -1;

  // no OpenGL (use canvas2D)
  glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);

  // create the only window
  auto window = glfwCreateWindow(600, 400, "Emscripten #22847", nullptr, nullptr);
  if(!window)
    return -1;

  // tell emscripten to use "main_loop" as the main loop (window is user data)
  emscripten_set_main_loop_arg(main_loop, window, 0, GLFW_FALSE);
}

What I need is the shell.html file (and/or changes to the cpp code) that would demonstrate the issue and what your expectations are.

The issue at hand is demonstrated by this code. Thanks for providing it.

How would you adjust this code so that the result can be resized using CSS without changing the framebuffer dimensions of the program?

[ypujante]

@michaelfiber

The issue at hand is demonstrated by this code. Thanks for providing it.

Can you provide me with the shell.html file you use that demonstrates the issue? Then I should be able to answer your question. Thank you.