#888
Issues/Immediate-Mode-UI/Nuklear/#888

[META::Emscripten] Live version integration strategy and progress report

OpenPavelSharpopened 8mo ago

The first step in integrating Emscripten is to choose the backend. See the report below.

Emscripten Integration Report

Good News

  1. ⭐⭐ Successfully built and tested demo/sdl3_renderer. Everything works, including builds with INCLUDE_ALL. However, this requires either merging the small PR #883 or manually fixing it by adjusting field types.
  2. ⭐ Successfully built and tested demo/sdl_opengles2. Everything works as expected. Untested with INCLUDE_ALL.
  3. ❌Successfully built demo/sdl_renderer. Launch is currently unsuccessful, since opening index.html results in an infinite loading loop. But I didn't take many attempts.

Bad News

  1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls. 1.1 The issue is described here issues/319. 1.2 There is an interesting PR #873 that introduces a have_mapbuffer flag, but it is always true. As a temporary workaround, its value could be set based on the __EMSCRIPTEN__ macro. 1.3 This PR will only fix demos including demo/glfw_opengl3, but the our examples (based on GLFW/OpenGL3 too) remain unchanged.
  2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in #590.

Notes

  1. Some work on Emscripten support has already been done by @DeXP:
    1.1. In the old repository, this PR added sdl_opengles2 and a web rule to Makefile. 1.2. About 10 years ago, a live version was created, but it is no longer maintained.
  2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

Activity

7
sleeptightAnsiC8mo ago

Thanks for the overall push on this one.

demo/sdl3_renderer

(disclaimer: I'm the "author" of this demo, so my take is biased) If this is not obvious for someone, the are several reasons why want to reuse demo/sdl3_renderer for live web demo: SDL3 is the most portable target with the biggest possible feature set; it was tested by several contributors and we fixed few bugs for it; main.c has huge config that makes it easy to compile; I keep patching and supporting it; Emscripten upstream itself is supporting SDL. Of course the best one would be SDL3+GLES2 or SDL3+WebGL but we don't have anything like this at the moment.

Bad News: 1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls.

Yes, this is a huge problem that we will need to solve somehow. For now, I think it would be fine to simply exclude some of those examples, and rewrite them later.

Bad News: 2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in https://github.com/Immediate-Mode-UI/Nuklear/pull/590.

IIRC, there are more problems in demo/sdl3_renderer that may prevent you from loading images. I believe, I just forgot to implement this functionality back in https://github.com/Immediate-Mode-UI/Nuklear/pull/852 and only recently noticed (shame on me...)

We can do a little bit of hacky-wacky approach, and still use unchanged demo/sdl3_renderer code by creating SDL_Renderer backed by GLES2 context (aka SDL_CreateRendererWithProperties with *_CREATE_NAME_STRING set to opengles2). If you're interested, let me know, and I'll give you some snippet.

Notes: 2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

According to https://github.com/emscripten-core/emscripten/issues/23831 the most up to date version of Emscripten should already ship with it's own SDL3 implementation, so in theory you should be able to do emmake make and the spoofed pkg-config should be able to pick that version. If that's not happening, then maybe there is something wrong with that makefile (?)

I'm planning to do some work on this demo, so I will most likely fix those issues too. If you (or anyone reading this) have any wishlist about some other features/fixes, let me know ;) Currently, there are several PRs open touching this code (https://github.com/Immediate-Mode-UI/Nuklear/pull/884, https://github.com/Immediate-Mode-UI/Nuklear/pull/878, https://github.com/Immediate-Mode-UI/Nuklear/pull/879, https://github.com/Immediate-Mode-UI/Nuklear/pull/841, more?) so I need to do something about them first.

also adding few refs:

sleeptightAnsiC8mo ago

Thanks for the overall push on this one.

Bad News: 1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls.

Yes, this is a huge problem that we will need to solve somehow. For now, I think it would be fine to simply exclude some of those examples, and rewrite them later.

Bad News: 2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in https://github.com/Immediate-Mode-UI/Nuklear/pull/590.

IIRC, there are more problems in demo/sdl3_renderer that may prevent you from loading images. I believe, I just forgot to implement this functionality back in https://github.com/Immediate-Mode-UI/Nuklear/pull/852 and only recently noticed (shame on me...)

We can do a little bit of hacky-wacky approach, and still use unchanged demo/sdl3_renderer code by creating SDL_Renderer backed by GLES2 context (aka SDL_CreateRendererWithProperties with *_CREATE_NAME_STRING set to opengles2). If you're interested, let me know, and I'll give you some snippet.

Notes: 2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

According to https://github.com/emscripten-core/emscripten/issues/23831 the most up to date version of Emscripten should already ship with it's own SDL3 implementation port, so in theory you should be able to do emmake make and the spoofed pkg-config should be able to pick that version. If that's not happening, then maybe there is something wrong with that makefile (?)

I'm planning to do some work on this demo, so I will most likely fix those issues too. If you (or anyone reading this) have any wishlist about some other features/fixes, let me know ;) Currently, there are several PRs open touching this code (https://github.com/Immediate-Mode-UI/Nuklear/pull/884, https://github.com/Immediate-Mode-UI/Nuklear/pull/878, https://github.com/Immediate-Mode-UI/Nuklear/pull/879, https://github.com/Immediate-Mode-UI/Nuklear/pull/841, more?) so I need to do something about them first.

also adding few refs:

sleeptightAnsiC8mo ago

Thanks for the overall push on this one.

Bad News: 1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls.

Yes, this is a huge problem that we will need to solve somehow. For now, I think it would be fine to simply exclude some of those examples, and rewrite them later.

Bad News: 2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in https://github.com/Immediate-Mode-UI/Nuklear/pull/590.

IIRC, there are more problems in demo/sdl3_renderer that may prevent you from loading images. I believe, I just forgot to implement this functionality back in https://github.com/Immediate-Mode-UI/Nuklear/pull/852 and only recently noticed (shame on me...) EDIT: I think, that demo doesn't need custom image handling, because it has no shaders involved and simply passthroughs the texture handle, but I'm not sure, if it works correctly, as I never tested it.

We can do a little bit of hacky-wacky approach, and still use unchanged demo/sdl3_renderer code by creating SDL_Renderer backed by GLES2 context (aka SDL_CreateRendererWithProperties with *_CREATE_NAME_STRING set to opengles2). If you're interested, let me know, and I'll give you some snippet.

Notes: 2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

According to https://github.com/emscripten-core/emscripten/issues/23831 the most up to date version of Emscripten should already ship with it's own SDL3 implementation port, so in theory you should be able to do emmake make and the spoofed pkg-config should be able to pick that version. If that's not happening, then maybe there is something wrong with that makefile (?)

I'm planning to do some work on this demo, so I will most likely fix those issues too. If you (or anyone reading this) have any wishlist about some other features/fixes, let me know ;) Currently, there are several PRs open touching this code (https://github.com/Immediate-Mode-UI/Nuklear/pull/884, https://github.com/Immediate-Mode-UI/Nuklear/pull/878, https://github.com/Immediate-Mode-UI/Nuklear/pull/879, https://github.com/Immediate-Mode-UI/Nuklear/pull/841, more?) so I need to do something about them first.

also adding few refs:

sleeptightAnsiC8mo ago

Thanks for the overall push on this one.

Bad News: 1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls.

Yes, this is a huge problem that we will need to solve somehow. For now, I think it would be fine to simply exclude some of those examples, and rewrite them later.

Bad News: 2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in https://github.com/Immediate-Mode-UI/Nuklear/pull/590.

IIRC, there are more problems in demo/sdl3_renderer that may prevent you from loading images. I believe, I just forgot to implement this functionality back in https://github.com/Immediate-Mode-UI/Nuklear/pull/852 and only recently noticed (shame on me...) EDIT: I think, that demo doesn't need custom image handling, because it has no shaders involved and simply passthroughs the texture handle, but I'm not sure, if it works correctly, as I never tested it.

We can do a little bit of hacky-wacky approach, and still use unchanged demo/sdl3_renderer code by creating SDL_Renderer backed by GLES2 context (aka SDL_CreateRendererWithProperties with *_CREATE_NAME_STRING set to opengles2). If you're interested, let me know, and I'll give you some snippet.

Notes: 2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

According to https://github.com/emscripten-core/emscripten/issues/23831 the most up to date version of Emscripten should already ship with it's own SDL3 port, so in theory you should be able to do emmake make and the spoofed pkg-config should be able to pick that version. If that's not happening, then maybe there is something wrong with that makefile (?) EDIT: added PR for this one: https://github.com/Immediate-Mode-UI/Nuklear/pull/894

I'm planning to do some work on this demo, so I will most likely fix those issues too. If you (or anyone reading this) have any wishlist about some other features/fixes, let me know ;) Currently, there are several PRs open touching this code (https://github.com/Immediate-Mode-UI/Nuklear/pull/884, https://github.com/Immediate-Mode-UI/Nuklear/pull/878, https://github.com/Immediate-Mode-UI/Nuklear/pull/879, https://github.com/Immediate-Mode-UI/Nuklear/pull/841, https://github.com/Immediate-Mode-UI/Nuklear/pull/894, more?) so I need to do something about them first.

also adding few refs:

sleeptightAnsiC8mo ago

(I'm well aware the text above is LLM-generated)

Thanks for the overall push on this one.

Bad News: 1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls.

Yes, this is a huge problem that we will need to solve somehow. For now, I think it would be fine to simply exclude some of those examples, and rewrite them later.

Bad News: 2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in https://github.com/Immediate-Mode-UI/Nuklear/pull/590.

IIRC, there are more problems in demo/sdl3_renderer that may prevent you from loading images. I believe, I just forgot to implement this functionality back in https://github.com/Immediate-Mode-UI/Nuklear/pull/852 and only recently noticed (shame on me...) EDIT: I think, that demo doesn't need custom image handling, because it has no shaders involved and simply passthroughs the texture handle, but I'm not sure, if it works correctly, as I never tested it.

We can do a little bit of hacky-wacky approach, and still use unchanged demo/sdl3_renderer code by creating SDL_Renderer backed by GLES2 context (aka SDL_CreateRendererWithProperties with *_CREATE_NAME_STRING set to opengles2). If you're interested, let me know, and I'll give you some snippet.

Notes: 2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

According to https://github.com/emscripten-core/emscripten/issues/23831 the most up to date version of Emscripten should already ship with it's own SDL3 port, so in theory you should be able to do emmake make and the spoofed pkg-config should be able to pick that version. If that's not happening, then maybe there is something wrong with that makefile (?) EDIT: added PR for this one: https://github.com/Immediate-Mode-UI/Nuklear/pull/894

I'm planning to do some work on this demo, so I will most likely fix those issues too. If you (or anyone reading this) have any wishlist about some other features/fixes, let me know ;) Currently, there are several PRs open touching this code (https://github.com/Immediate-Mode-UI/Nuklear/pull/884, https://github.com/Immediate-Mode-UI/Nuklear/pull/878, https://github.com/Immediate-Mode-UI/Nuklear/pull/879, https://github.com/Immediate-Mode-UI/Nuklear/pull/841, https://github.com/Immediate-Mode-UI/Nuklear/pull/894, more?) so I need to do something about them first.

also adding few refs:

sleeptightAnsiC8mo ago

(I'm well aware the text above is LLM-generated/edited)

Bad News: 1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls.

Yes, this is a huge problem that we will need to solve somehow. For now, I think it would be fine to simply exclude some of those examples, and rewrite them later.

Bad News: 2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in https://github.com/Immediate-Mode-UI/Nuklear/pull/590.

IIRC, there are more problems in demo/sdl3_renderer that may prevent you from loading images. I believe, I just forgot to implement this functionality back in https://github.com/Immediate-Mode-UI/Nuklear/pull/852 and only recently noticed (shame on me...) EDIT: I think, that demo doesn't need custom image handling, because it has no shaders involved and simply passthroughs the texture handle, but I'm not sure, if it works correctly, as I never tested it.

We can do a little bit of hacky-wacky approach, and still use unchanged demo/sdl3_renderer code by creating SDL_Renderer backed by GLES2 context (aka SDL_CreateRendererWithProperties with *_CREATE_NAME_STRING set to opengles2). If you're interested, let me know, and I'll give you some snippet.

Notes: 2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

According to https://github.com/emscripten-core/emscripten/issues/23831 the most up to date version of Emscripten should already ship with it's own SDL3 port, so in theory you should be able to do emmake make and the spoofed pkg-config should be able to pick that version. If that's not happening, then maybe there is something wrong with that makefile (?) EDIT: added PR for this one: https://github.com/Immediate-Mode-UI/Nuklear/pull/894

I'm planning to do some work on this demo, so I will most likely fix those issues too. If you (or anyone reading this) have any wishlist about some other features/fixes, let me know ;) Currently, there are several PRs open touching this code (https://github.com/Immediate-Mode-UI/Nuklear/pull/884, https://github.com/Immediate-Mode-UI/Nuklear/pull/878, https://github.com/Immediate-Mode-UI/Nuklear/pull/879, https://github.com/Immediate-Mode-UI/Nuklear/pull/841, https://github.com/Immediate-Mode-UI/Nuklear/pull/894, more?) so I need to do something about them first.

also adding few refs:

sleeptightAnsiC8mo ago

(I'm well aware the text above is LLM-generated/edited)

Bad News: 1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls.

Yes, this is a huge problem that we will need to solve somehow. For now, I think it would be fine to simply exclude some of those examples, and rewrite them later.

Bad News: 2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in https://github.com/Immediate-Mode-UI/Nuklear/pull/590.

IIRC, there are more problems in demo/sdl3_renderer that may prevent you from loading images. I believe, I just forgot to implement this functionality back in https://github.com/Immediate-Mode-UI/Nuklear/pull/852 and only recently noticed (shame on me...) EDIT: I think, that demo doesn't need custom image handling, because it has no shaders involved and simply passthroughs the texture handle, but I'm not sure, if it works correctly. I never tested it.

We can do a little bit of hacky-wacky approach, and still use unchanged demo/sdl3_renderer code by creating SDL_Renderer backed by GLES2 context (aka SDL_CreateRendererWithProperties with *_CREATE_NAME_STRING set to opengles2). If you're interested, let me know, and I'll give you some snippet.

Notes: 2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

According to https://github.com/emscripten-core/emscripten/issues/23831 the most up to date version of Emscripten should already ship with it's own SDL3 port, so in theory you should be able to do emmake make and the spoofed pkg-config should be able to pick that version. If that's not happening, then maybe there is something wrong with that makefile (?) EDIT: added PR for this one: https://github.com/Immediate-Mode-UI/Nuklear/pull/894

I'm planning to do some work on this demo, so I will most likely fix those issues too. If you (or anyone reading this) have any wishlist about some other features/fixes, let me know ;) Currently, there are several PRs open touching this code (https://github.com/Immediate-Mode-UI/Nuklear/pull/884, https://github.com/Immediate-Mode-UI/Nuklear/pull/878, https://github.com/Immediate-Mode-UI/Nuklear/pull/879, https://github.com/Immediate-Mode-UI/Nuklear/pull/841, https://github.com/Immediate-Mode-UI/Nuklear/pull/894, more?) so I need to do something about them first.

also adding few refs: