[core] Very low rendering quality on 4K displays on PLATFORM_WEB

[ypujante]

I have been trying to port my application RE Edit which is a raylib/ImGui application to the web platform to offer a demo (since there is no filesystem access available I cannot really run it in a browser until it is available in wasm...)

I have a prototype running and it looks quite bad:

• On macOS (showing web on the left, native on the right):

• On Windows (showing that the resolution is 4K on the left, web on the right):

I have created a small reproducible test case to show the issue which uses raylib only (top is web, bottom is native):

The source code for the test case is this:

#include "raylib.h"

int main()
{
  InitWindow(800, 450, "raylib [core] example - basic window");

  SetTargetFPS(60);

  while (!WindowShouldClose())
  {
    BeginDrawing();
    ClearBackground(RAYWHITE);
    DrawText("The quick brown fox jumps over the lazy dog", 10, 10, 20, BLACK);
    DrawText("Congrats! You created your first window!", 10, 40, 20, LIGHTGRAY);
    DrawFPS(10, 70);

    EndDrawing();
  }

  CloseWindow();

  return 0;
}

Is this a bug in raylib? A bug in glfw3? Or a misconfiguration? I have followed the steps described here but there isn't any mention of the quality of the rendering nor how to make it look better on 4K displays.

[ghost]

@ypujante Could you please test it with minshell.html instead of shell.html. shell.html has a width:100%; CSS (L79) which is likely affecting the scaling. Or just delete L79 from shell.html.

Edit: added line marks; editing.

[ypujante]

@ubkp I would gladly test it but I don't know what you mean by using minshell.html. The compilation produces this set of files:

-rw-r--r--@  1 ypujante  staff     1678 Oct  3 09:58 raylib_web_cmake.data
-rw-r--r--@  1 ypujante  staff   102483 Oct  3 09:58 raylib_web_cmake.html
-rw-r--r--@  1 ypujante  staff   268052 Oct  3 09:58 raylib_web_cmake.js
-rwxr-xr-x@  1 ypujante  staff  1601058 Oct  3 09:58 raylib_web_cmake.wasm*

The file raylib_web_cmake.html only contains this section:

      #output {
        width: 100%;
        height: 200px;
...

Commenting out width: 100% or turning it on/off in the browser makes no difference

[ghost]

@ypujante When compiling with emscripten (check this) you'll, at some point, pass which shell file it should use. It's likely defaulting to -shell-file shell.html.

Option 1. Go to the src dir and edit the shell.html file to delete this line (L79) from it. Then recompile.

Option 2. Open your cmake file, search for -shell-file shell.html, change it to -shell-file minshell.html. Then recompile.

Edit: Option 3. Go to the src dir, rename shell.html to shell.html.old. Then rename minshell.html to shell.html. Then recompile.

[ypujante]

I used option 2 (the options is --shell-file not -shell-file).

The result is the same. No difference at all

[ghost]

@ypujante Do you have this case on a repository or branch that I could download to test?

[ypujante]

Here is the (self contained) project with instructions to build in CMakeLists.txt

raylib-web-cmake.zip

# build instructions
# mkdir build
# cd build
# cmake .. -DCMAKE_TOOLCHAIN_FILE=/usr/local/emsdk/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake -DPLATFORM=Web -DCMAKE_BUILD_TYPE=Debug
# cmake --build . --target raylib_web_cmake

Make sure to replace CMAKE_TOOLCHAIN_FILE with your emscripten location

[ypujante]

Also for the record, I just swapped the embedded raylib (self contained in the project) with master as of this morning. There is no difference.

[ghost]

@ypujante Okay. I'm rebuilding emscripten here to test.

[ghost]

@ypujante Thanks for the zip file, it helped a lot.

Unfortunately, I was not able to replicate the issue. Tested it here right now on Firefox (111.0.1 64-bit) and Chromium (117.0.5938.132 64-bit) both running on Linux (Fedora 38 64-bit) and it appears to be rendering correctly for me on both:

[ypujante]

Thank you for testing. Are you on a 4K monitor? I have tested only on Windows and macOS with 4K monitors. Both have the issue.

Here is my build in case you want to try it as well (in case it is a build problem)

rwc.tgz

[ghost]

@ypujante I tested it on a LG UHD TV 4K.

Tried testing your rwc.tgz but it's missing the .data file. Could you reupload it?

[ypujante]

Actually I would argue that your test shows the problem. If you zoom in, you can see that there is aliasing around the edges of the letter. Aliasing which is NOT present in the native application.

I captured with my phone what I am talking about:

macOS web => aliasing around the letters

macOS native => NO aliasing

linux web (what you uploaded) => aliasing around the letters which is identical to what I see

[ypujante]

Not sure why .data is required but here it is:

rwc.tgz

[ypujante]

I also uploaded my "real" test (note that it is 20MB: https://github.com/pongasoft/re-edit/releases/download/v1.6.2/RE-Edit-wasm.tgz). It contains 3 files (note that there is a space in the filename which needs to be converted to %20 when you generate the URL: RE%20Edit.html)

This generates the output as seen in the screenshot on my first post

[ghost]

@ypujante The .data file is required because without it there's this error:

Here are my results for rwc.tgz:

I really can't notice the edges issue (but that could be my bad eyesight). But by your zoom photos it could be another of those OpenGL ES blending issues.

[ypujante]

Since you have the source code you could also build the native version and compare side by side...

[ghost]

@ypujante Sure, just a moment to check the HTML/CSS. Just to be sure it's not messing the render.

[ghost]

@ypujante I trimmed the HTML/CSS to the bare minimum and fixed everything to 600x500 to assure no scaling conflicts. The window with black background:

And it with a red background (notice the edging):

My best guess is that this could be another OpenGL ES blending issue.

Edit: compiled native on Linux (Fedora 38 64-bit):

[raysan5]

@ypujante @ubkp I'm afraid it could be related to platform/OS/drivers, not sure if it can be controlled from raylib side, or at least I have no idea what it could be related.

[ypujante]

I ran another experiment rendering with the browser, rendering with the canvas api and rendering with raylib.

Rendering with html is:

<p style="font-family: 'Jetbrains Mono', sans-serif; font-size: 27px; margin-left: 10px">
  The quick brown fox jumps over the lazy dog
  <br>
  <img id="logo" src="logo_dark_128x128.png" alt="logo" width="64"/>
</p>

Rendering with canvas is:

  const ctx = document.getElementById('c2d').getContext('2d');
  ctx.font = "27px 'Jetbrains Mono'";
  ctx.fillText("The quick brown fox jumps over the lazy dog", 10, 50);
  const logo = document.getElementById('logo');
  ctx.drawImage(logo, 10, 10, 64, 64);

Clearly the browser is by far the best rendering. And the direct canvas API gives a similar result than raylib. Maybe there is a way to configure the canvas itself to be higher resolution. Not sure...

[ghost]

@ypujante Perhaps you could try these:
- https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D
- https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/globalAlpha
- https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/globalCompositeOperation
- https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/imageSmoothingEnabled
- https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/imageSmoothingQuality

Edit: see #3372 (comment).

[ghost]

@ypujante This looks fairly close to the problem:

• https://stackoverflow.com/questions/15661339/how-do-i-fix-blurry-text-in-my-html5-canvas
• https://web.dev/canvas-hidipi/

[ghost]

@ypujante You were on the right track. Following and adapting this tutorial I think these could be the results you're looking for:

<!doctype html>
<html lang="EN-us">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>test</title>
    <meta name="viewport" content="width=device-width">
    </head>
    <body>
 
<p style="font-family:sans-serif; font-size:27px; margin-left: 10px">
    The quick brown fox jumps over the lazy dog
</p>

<canvas id="canvas" width="800" height="200">
</canvas>

<script>
    window.devicePixelRatio=4;

    var canvas = document.getElementById('canvas');
    var currentWidth = canvas.width;
    var currentHeight = canvas.width;
    canvas.style.width = currentWidth + "px";
    canvas.style.height = currentHeight + "px";
    var scale = window.devicePixelRatio;
    canvas.width = Math.floor(currentWidth * scale);
    canvas.height = Math.floor(currentHeight * scale);

    const ctx = document.getElementById('canvas').getContext('2d');
    ctx.scale(scale, scale);
    ctx.font = "27px 'sans-serif'";
    ctx.fillText("The quick brown fox jumps over the lazy dog", 10, 50);
</script>

    </body>
</html>

[ypujante]

Thank you for the follow up.

So indeed, looking at the more "official" documentation about devicePixelRatio shows the same kind of example. But clearly window.devicePixelRatio is read not written and is automatically set to 2 for HiDPI / Retina display.

This entirely fixes the blurry rendering of my "Canvas" entry in my previous example:

  console.log("window.devicePixelRatio=" + window.devicePixelRatio);
  const canvas = document.getElementById('c2d');
  var currentWidth = canvas.width;
  var currentHeight = canvas.height;
  canvas.style.width = currentWidth + "px";
  canvas.style.height = currentHeight + "px";
  const scale = window.devicePixelRatio;
  canvas.width = Math.floor(currentWidth * scale);
  canvas.height = Math.floor(currentHeight * scale);
  const ctx = canvas.getContext('2d');
  ctx.scale(scale, scale);
  ctx.font = "27px 'Jetbrains Mono'";
  ctx.fillText("The quick brown fox jumps over the lazy dog", 10, 50);
  const logo = document.getElementById('logo');
  ctx.drawImage(logo, 10, 10, 64, 64);

Both the logo and the text are now as sharp as the "Browser" section.

Trying to apply a similar modification to the raylib section unfortunately fails with the following errors

WARNING: GLFW: Failed to initialize Window
FATAL: Failed to initialize Graphic Device

Going to investigate this failure further...

[ghost]

@ypujante Are you trying to apply it on the shell.html file? Or from inside raylib with EM_JS() or EM_ASM() (doc)?

[ypujante]

I modified shell.html as I was not aware of EM_JS(). But I feel like this is not really going to work by following this same pattern. Stepping through the code I see this:

 createContext(canvas, useWebGL, setInModule, webGLContextAttributes) {
  if (useWebGL && Module.ctx && canvas == Module.canvas) return Module.ctx;
  var ctx;
  var contextHandle;
  if (useWebGL) {
   var contextAttributes = {
    antialias: false,
    alpha: false,
    majorVersion: 1
   };
   if (webGLContextAttributes) {
    for (var attribute in webGLContextAttributes) {
     contextAttributes[attribute] = webGLContextAttributes[attribute];
    }
   }
   if (typeof GL != "undefined") {
    contextHandle = GL.createContext(canvas, contextAttributes);
    if (contextHandle) {
     ctx = GL.getContext(contextHandle).GLctx;
    }
   }
  } else {
   ctx = canvas.getContext("2d");
  }
  if (!ctx) return null;
  if (setInModule) {
   if (!useWebGL) assert(typeof GLctx == "undefined", "cannot set in module if GLctx is used, but we are a non-GL context that would replace it");
   Module.ctx = ctx;
   if (useWebGL) GL.makeContextCurrent(contextHandle);
   Module.useWebGL = useWebGL;
   Browser.moduleContextCreatedCallbacks.forEach(callback => callback());
   Browser.init();
  }
  return ctx;
 },

and the line ctx = GL.getContext(contextHandle).GLctx is the one being executed.

Not knowing this code (nor even if this code comes from raylib / glfw or emscripten) I do not know what is the relationship between GL.getContext(contextHandle).GLctx and canvas.getContext("2d") neither if it is modifiable after creation, etc...

[ghost]

@ypujante I don't have access to a compiler right now to test it, but my first try would be setting the devicePixelRatio and canvas fix exactly one line before the canvas initialization by raylib. To be specific, on your shell file, something like this:

[...]
    <body>
        <canvas class=emscripten id=canvas oncontextmenu=event.preventDefault() tabindex=-1></canvas>
        <p id="output" />
        <script>

            // DEVICE PIXEL RATIO
            // AND CANVAS FIX
            // GOES EXACTLY HERE

            var Module = {
                print: (function() {
                    var element = document.getElementById('output');
                    if (element) element.value = ''; // clear browser cache
                    return function(text) {
                        if (arguments.length > 1) text = Array.prototype.slice.call(arguments).join(' ');
                        console.log(text);
                        if (element) {
                          element.value += text + "\n";
                          element.scrollTop = element.scrollHeight; // focus on bottom
                        }
                    };
                })(),
                canvas: (function() {
                    var canvas = document.getElementById('canvas');
                    return canvas;
                })()
            };
        </script>
        {{{ SCRIPT }}}
    </body>
[...]

[ypujante]

As I mentioned, devicePixelRatio already contains the correct value and should not be modified.

It is not working either, because as soon as you do canvas.getContext('2d') it creates the context (in order to call setScale on it). When the code then tries to create the GL context (contextHandle = GL.createContext(canvas, contextAttributes);) it fails.

I am going to see if I can do it after the fact using ES_ASM...

[ypujante]

The context created is of type WebGLRenderingContext and does not have a setScale method. I am looking into whether there is another way to deal with this issue when the content is WebGLRenderingContext

[raysan5]

@ypujante I'm not sure if much can be done on raylib side, it looks like scaling is managed by browser, display and drivers.

[niorad]

Having a larger canvas and shrinking it via CSS to the browser-width is how high-dpi is handled for most browser-games.
Usually the canvas' actual size is double the display size.
I was able to solve the mouse-issue by using a camera and getting mouse-coordinates with

GetScreenToWorld2D(GetMousePosition(), camera);

[raysan5]

So the rendering problem is solved, but the mouse position is wrong.

@ypujante you can use SetMouseScale() and SetMouseOfsset() to adjust that.

The WebGPU solution could be maybe applied in raylib?

@niorad thanks for the additional info! Making the canvas double size could imply an important performance-hit.

[ypujante]

@raysan5 it's true that SetMouseScale() and SetMouseOfsset() would address the solution.

The WebGPU solution is essentially what I have been trying to do all along and I am working (or at least trying to) work on a solution that would involve implementing these changes in emscripten with a flag to turn it on/off so that the glfw layer does the right thing (scale framebuffer 2x, return mouse coordinates in 1x coordinates).

I believe this might require a couple tweaks to raylib once the glfw layer is implemented as there are some assumptions that would not be correct anymore. If I am successful with my changes in emscripten (and they get accepted/integrated), I will submit a PR for raylib as well...

[ypujante]

I have some very good news. I was able to change the emscript layer and raylib layer (some tweaks required for the web platform) so that 4k/retina is supported.

The only change from a user point of view is to add a Module.isHiDPIAware variable. In my proof of concept it is even read from the query string (view the source to check how I do it). But the rest of the code is transparent...

Here is the proof of concept:

• HiDPIAware enabled
• HiDPIAware disabled

You must use Chrome as webgpu is not supported by any other browser as far as I know.

If you are not on a 4k/retina display then the 2 links will render the same thing. Also dragging the browser window from a 4k screen to a 2k screen (and vice versa) also works perfectly :)

Here are the 2 different outputs:

• HiDPIAware disabled (or rendered on a 2k monitor)
  

• HiDPIAware enabled (and rendered on a 4k monitor)
  

Now I need to work with emscript people to see if my changes can be integrated. And if that happens, then I will need to see how to have my changes integrated with raylib hopefully...

[raysan5]

@ypujante thank you very much for investigating this improvement, keep us updated! I'll keep the issue open in the meantime.

[ypujante]

As an FYI, I created the pull request for emscripten . The pull request contains 2 more live demos with dynamic switching between 2k/4k (no need to reload the page with a different query string) if you are interested. They demonstrate how to have the canvas taking the fullscreen and resizing as the window gets resized, or have the canvas have a static size (while still allowing for fullscreen rendering which removes the shell). 2 very different code paths which were not easy to both get working...

[raysan5]

@ypujante thanks for the further investigation and the results! It seems the PR is progressing in emscripten side, hopefully it will be merged soon! I think we can close this PR for now as the issue has moved out of raylib.

Let me know if that's ok for you, I can reopen it if required.

Thank you very much again for all your time and deep investigation of this issue, amazing work! :)

[ypujante]

Technically there are changes that need to happen in raylib as well. I can't issue a PR yet until the changes are integrated into emscripten.

[raysan5]

@ypujante Ok, no problem! Reopening! 😄

[ypujante]

@raysan5 I am still waiting for the emscripten pull request to be merged but I wanted to let you know that I have forked and pushed the changes required for raylib on my fork

In case you are interested to integrate them prior to emscripten changes since it is 100% backward compatible:

• the code changes calls glfwGetFramebufferSize which currently returns width/height so it still works
• note that the EmscriptenResizeCallback can be simplified in any case since calling SetWindowSize ends up calling the callback so no real need to force changing the size of the canvas directly like you do (which bypasses glfw which I believe is not proper in the first place...)
• whenever the changes are applied to emscripten, it doesn't automatically switch to 4k since you have to enable 4k in the first place

Let me know if you want me to create a pull request for it or you still prefer to wait. I am fine either way (but consider revisiting the EmscriptenResizeCallback callback...)

[raysan5]

@ypujante Feel free to open a PR for review and further discusdion.

[ypujante]

Closing this issue for now. When/if emscripten changes are merged I might reopen it/revisit it.

[raysan5]

Closing this issue for now. When/if emscripten changes are merged I might reopen it/revisit it.

I think the amount of changes and integration cost could be smaller when emscripten merges those reviews...

[ypujante]

@raysan5 I want to apologize for taking more of your time. I just wanted to follow up on your comments about the fact that whenever changes are made you "inherit" the burden of having to understand and maintain it after the fact.

I think with the tremendous work on splitting per platform as was accomplished, this opens up the road for user contributed platforms that you do not own/maintain. I am not sure if this is something that is already possible or if you are thinking about it for the future, but maybe something to consider.

In this specific instance, if there was a way for me to offer a PLATFORM_WEB_HI_DPI that is neither written nor maintained by you, then that would still allow for users who care about Hi DPI rendering to use raylib with a different platform while not changing any of the core platforms supported by raylib or burdening you with more work.

Essentially a platform plugin sort of thing. How that would be implemented in raylib, or even if it is possible or a direction you would consider is obviously not for me to decide.

This is just food for thoughts at this stage.

Thank you

[raysan5]

Hi @ypujante, I also want to apologize, I know you put a lot of work and time into this issue and the PR was rejected quite abruptly. At this moment I'm quite overloaded with raylib 5.0 release but after it and Emscripten update, those improvements could be reviewed again if you wish.

I think with the tremendous work on splitting per platform as was accomplished, this opens up the road for user contributed platforms that you do not own/maintain. I am not sure if this is something that is already possible or if you are thinking about it for the future, but maybe something to consider.

Yes. The platform-split is really new and that's one of the objectives: allowing the addition of custom platform backends; actually I'm already aware of some users working on that line and even yesterday @ubkp proposed the addition of PLATFORM_WEB_SDL. I don't know yet how to manage those additions (code-plug-ins?), if they should be integrated into raylib (and assign platform-maintainers/heroes) or let it be managed externally by its creators in separate repos (similar to bindings). From an integration point of view, first options seems the most feasible but implies other considerations: abbandoned platforms, maintainers not responding, issue-management, documentation, raylib rcore glue-code...

As commented on previous posts, it would be great a PLATFORM_WEB_NATIVE, not GLFW-dependant, implemented directly over Emscripten, maybe you could be interested on it? It could include the custom HighDPI-aware changes and you could be designed as the official maintainer of that platform.

Note that there is already a platforms/rcore_template.c intended to be a guide for new platforms addition, currently all platforms follow that structure and it could simplify a lot the understanding and maintenance of new platform implementations. As a side note, I also used that template for Nintendo Switch implementation and it worked perfectly.

As a said, this platform-split redesign is a big change for raylib and I don't know what could be the implications for the future of the library, hopefully it is for good.

Thanks again for your time and the work put in raylib.

[ypujante]

@raysan5 what is the proper way for starting a discussion about the topic of using low level emscripten apis (Browser) vs glfw. A github issue? Or a github discussion? And obviously this is not urgent and can wait until you are done with 5.0 release... Just want to create the starting point in order to keep track of it/not forget about it...

[raysan5]

@ypujante I think a GitHub Issue is the best option...

[ypujante]

@raysan5 I just wanted to let you know that my changes in emscripten that are necessary to address this issue are now available in the latest emscripten released yesterday: 3.1.51. From the Changelog:

Added Hi DPI support to GLFW. When enabled, GLFW automatically accounts for the devicePixelRatio browser property and changes the size of the canvas accordingly (including dynamically if the canvas is moved from a 4K screen to a 2K screen and vice-versa). glfwGetFramebufferSize now properly returns the canvas size in pixels, while glfwGetWindowSize returns the canvas size is screen size. By default, this feature is disabled. You can enable it before creating a window by calling glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE). You can also dynamically change it after the window has been created by calling glfwSetWindowAttrib(window, GLFW_SCALE_TO_MONITOR, GLFW_TRUE). (#20584)

If you, or anybody else want to make the necessary changes in raylib to be able address this "issue" (or another way to look at it is "enhance raylib to support hi dpi on the web platform") you can now do so.

On my side, given the borderline hostile feedback I have received (both on Discord and github) every time I have tried to contribute in making the project better (albeit not by you, but by others), I have decided that I am no longer be contributing to this project directly and I am going to follow the guidance you provided in your comment and simply create my own fork/platform to do this (and future) work.

[raysan5]

I just wanted to let you know that my changes in emscripten that are necessary to address this issue are now available in the latest emscripten released yesterday: 3.1.51.

Oh! That's great! Thanks you very much for working on this improvement and pushing it to emscripten. I added glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE) on InitWindow() for PLATFORM_WEB but commented until the automatic build system gets updated to latest emscripten.

On my side, given the borderline hostile feedback I have received (both on Discord and github) every time I have tried to contribute in making the project better (albeit not by you, but by others), I have decided that I am no longer be contributing to this project directly and I am going to follow the guidance you provided in your #3596 (comment) and simply create my own fork/platform to do this (and future) work.

I'm really sorry to read that. I never pretended to make you feel unconfortable contributing to raylib project, I always try to be friendly and respectful with all contributors and I sincerely appreciate a lot all the work put on any contribution. I know community could be a bit harsh (specially Discord) but I also think communication could be difficult though those platforms and some words could sound worse than the real feeling behind it. Personally, English is not my first language and sometimes it's difficult for me to find the proper words to not sound rude. In any case, I'm sorry again you leave the project with this feeling, you will be always welcome to contribute again when you want.

[ypujante]

Oh! That's great! Thanks you very much for working on this improvement and pushing it to emscripten. I added glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE) on InitWindow() for PLATFORM_WEB but commented until the automatic build system gets updated to latest emscripten.

It won't be enough. You also need to use glfwGetFramebufferSize. Note that ImGui uses glfw the proper way but raylib does not. So simply adding glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE) to ImGui works like a charm, but you will have to make additional changes to raylib. You can see an example of the changes that I had implemented in the PR.

I am currently working on a full blown c++/emscripten port of glfw3 and for my tests I use OpenGL directly and this is the code I have:

  glfwMakeContextCurrent(fWindow);
  glClearColor(fBgRed, fBgGreen, fBgBlue, fBgAlpha);
  int width = 0, height = 0;
  glfwGetFramebufferSize(fWindow, &width, &height);
  glViewport(0, 0, width, height);
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

The real critical part is that the viewport needs to be set with the values coming from glfwGetFramebufferSize.

I'm really sorry to read that. I never pretended to make you feel unconfortable contributing to raylib project, I always try to be friendly and respectful with all contributors and I sincerely appreciate a lot all the work put on any contribution. I know community could be a bit harsh (specially Discord) but I also think communication could be difficult though those platforms and some words could sound worse than the real feeling behind it. Personally, English is not my first language and sometimes it's difficult for me to find the proper words to not sound rude. In any case, I'm sorry again you leave the project with this feeling, you will be always welcome to contribute again when you want.

As I pointed out in my comment, you are not the one who have made me feel uncomfortable.