example_emscripten_wgpu is throwing an error in InitWGPU function

[gautam1168]

I am building the emscripten example on windows. The console in the browser throws an error saying

Uncaught RuntimeError: Aborted(Assertion failed: WGPUInstance must be created by wgpuCreateInstance)
    at abort (index.js:676:11)
    at assert (index.js:366:5)
    at _wgpuInstanceCreateSurface (index.js:4598:7)
    at index.wasm:0x8a3f2
    at index.wasm:0x15df
    at index.js:733:22
    at callMain (index.js:5231:15)
    at doRun (index.js:5281:23)
    at index.js:5292:7

I am able to fix this by changing the line in the InitWGPU function to use the function mentioned in the error like this

wgpu::Instance instance = {}; 

becomes

wgpu::Instance instance = wgpu::CreateInstance(); //{};

After this I am able to see the ui in the browser.

Additionally, I was unable to compile the example in windows unless I removed this line from the MakeFile

# UNAME_S := $(shell uname -s)

I am unsure if I am fixing something correctly here or just using it in a way that is not the intended way to use it.

[Traveller23]

I'm experiencing the same error and waiting for the answer.

By the way, I can compile successfully under Windows 10 with the latest emscripten, with or without code modifications. It's just that the browser reports the above error if I don't modify the code.

[sairus7]

wgpu::Instance instance = wgpu::CreateInstance(); //{};

Thanks, changing this line helped! But now I get very low-resolution version. Any clues why?

[Traveller23]

wgpu::Instance instance = wgpu::CreateInstance(); //{};

Thanks, changing this line helped! But now I get very low-resolution version. Any clues why?

It's not a bug, it's just set up that way on purpose.
You can prevent stretching by modifying index.html:

$ git diff HEAD -- web/index.html
diff --git a/examples/example_emscripten_wgpu/web/index.html b/examples/example_emscripten_wgpu/web/index.html
index 82b1c422..35a3efd7 100644
--- a/examples/example_emscripten_wgpu/web/index.html
+++ b/examples/example_emscripten_wgpu/web/index.html
@@ -12,8 +12,6 @@
             left: 0px;
             margin: 0px;
             border: 0;
-            width: 100%;
-            height: 100%;
             overflow: hidden;
             display: block;
             image-rendering: optimizeSpeed;

[sairus7]

@Traveller23 Thanks, I removed those two lines and now it renders with the same resolution just not in fullscreen:

Where would I know about these settings?

[Traveller23]

@Traveller23 Thanks, I removed those two lines and now it renders with the same resolution just not in fullscreen:

Where would I know about these settings?

Your screenshot shows that your viewport's size is 1280x720, but the actual size of the light blue part of the screenshot is 1600x900, so I'm guessing you're using your browser's zoom. You should leave the browser's zoom level at 100%.

This 1280x720 is defined in main.cpp, you can find it by searching for "glfwCreateWindow". There should not be any scaling of ImGui's screen output.

[sairus7]

Thanks a lot, there was zoom indeed!

I've tried to change glfwCreateWindow constants or use this solution https://stackoverflow.com/questions/53752243/how-to-retrieve-in-browser-size-of-emscripten-canvas

But with no effect on window actual size.

[sairus7]

Looks like there is some problem with updating wasm after recompilation, since server doesn't change GUI despite of any changes I make in main.cpp.

[sairus7]

So, looks like my browser caches wasm modules somehow. So it updates only when I open it in incognito mode (they differ in window size and number of bangs):

How can I control this setting?

[sairus7]

Still, I don't understand, how can I get actual browser screen size to fit window in glfwCreateWindow.
With emscripten_get_canvas_element_size("#canvas", &width, &height); I get 300x150 pixels (same as here).
With emscripten_get_screen_size(&width, &height); I get full monitor resolution 1920x1080 but not browser window.

[sairus7]

Solved it by changing back in html-file

            width: 100%;
            height: 100%;

And the following code:

EM_JS(int, browser_get_width, (), {
    const { width, height } = canvas.getBoundingClientRect();
    return width;
});

EM_JS(int, browser_get_height, (), {
    const { width, height } = canvas.getBoundingClientRect();
    return height;
});

// usage
width = browser_get_width(); // 1280
height = browser_get_height(); // 720
GLFWwindow* window = glfwCreateWindow(width, height, "Dear ImGui GLFW+WebGPU example", nullptr, nullptr);

[Traveller23]

@sairus7 Your question is way off-topic, and this will have an impact on the handling of this issue.
For questions not related to ImGui itself, I suggest you ask on stackoverflow.

[ocornut]

Question is off topic, but that said, if there’s an issue with our example not scaling properly on some setup it should be fixed in the example (html or c++ side). @Traveller23 do you have an opinion on the right way to fix this issue?

[Traveller23]

Question is off topic, but that said, if there’s an issue with our example not scaling properly on some setup it should be fixed in the example (html or c++ side). @Traveller23 do you have an opinion on the right way to fix this issue?

As mentioned above, just delete the two lines in index.html.
The auto-generated index.html doesn't force ImGui's canvas to be stretched, so it shouldn't be stretched here either.

In order to maintain the simplicity of the example, and the uniformity of all the examples, I don't recommend a more advanced way of getting the size of the canvas in C++.

[ocornut]

Merged fix 981abb4.

@Traveller23 If I remove the 100% specifiers in https://github.com/ocornut/imgui/blob/master/examples/libs/emscripten/shell_minimal.html then the examples canvas doesn't fill available space which is really undesirable IHMO. I would like our example to use as much space is available and update resolution accordingly, so it looks closer to a fullscreen application, rather than being in a "small" canvas like Emscripten default html template or a fixed resolution.

So when the browser window is resized from SDL/GLFW point of view it should be equivalent to a native Windows being resized and we use all that space.

[Traveller23]

@ocornut I see what you're trying to do, so a little more advanced and complex method is inevitable. In addition to the need to get the size of the canvas at initialization time, you also need to resize canvas as well as framebuffer when the window size changes.

I'll submit a pull request soon.

[ocornut]

Thanks!
Interesting it did seem to work already on some setups but not all (maybe was browser specific, I forgot). Something that works everywhere would be great.

[Traveller23]

Submitted: #6751

By the way, the latest code (commit 2000537) still outputs jagged text on my machine. (Windows 10 + chrome 116) .

[ocornut]

By the way, the latest code (commit 2000537) still outputs jagged text on my machine. (Windows 10 + chrome 116) .

I am sorry I don't know what you are referring to here by jagged text? Is your framebuffer missized on current master?
It doesn't for me. But if you are telling me that your PR fixes it that's good.

[Traveller23]

By the way, the latest code (commit 2000537) still outputs jagged text on my machine. (Windows 10 + chrome 116) .

I am sorry I don't know what you are referring to here by jagged text? Is your framebuffer missized on current master? It doesn't for me. But if you are telling me that your PR fixes it that's good.

I apologize for my lack of description.
What I mean is that until I apply my pull request, I get the same output as before:

Because you said that after applying this (981abb4) update, some machines no longer have the jaggedness problem, so I reported my situation.

[ocornut]

Thanks! Moved this to #6751, i know understand that SDL does a similar thing as you did, and GLFW doesn't, and this is why our current Makefile for the GLFW side use a different template as the one used by SDL example makefile.