3 ms·

I made my own WASM demo @ https://microui-wasm.vercel.app/ https://microui-wasm.vercel.app/ and it's only 14.6 kB compressed! Will share source code if someone

by onsclom 4mo ago

I made my own WASM demo @ https://microui-wasm.vercel.app/ https://microui-wasm.vercel.app/ and it's only 14.6 kB compressed! Will share source code if someone is interested, but key bits: - had a small JS glue layer using CanvasRenderingContext2D to render - made a `wasm32-freestanding` build to lower the wasm bundle size, which meant shimming the bits of the libc microui uses

Narishma 4mo ago
Your demo seems to constantly consume 100% CPU at all times.
- onsclom 4mo ago
  Ooh interesting. What is your machine and browser? On chrome with my m1 macbook it takes less than 1ms to compute and render each frame, but I am noticing some things I can optimize from the performance flame graph! I will say, I find chrome to be way more efficient for ctx2d things than firefox or safari.
  - Narishma 4mo ago
    Firefox on Linux.
  - Lockal 4mo ago
    Chrome on Linux suffers from this too. The issues are standard for all naive immediate GUI libs: - constant repainting (while literally nothing changes) -> constant CPU load - some libs can skip repaints but have no concept of damage area - bad handling of high-dpi (which also can change dynamically) - constant repainting behaves even worse on laptops which announce 180 Hz refresh interval, which means that it drains the battery 3 times faster than 60 Hz
    - flohofwoe 4mo ago
      > - constant repainting (while literally nothing changes) -> constant CPU load This doesn't explain a 100% CPU usage since requestAnimationFrame is vsync-throttled and rendering such a simple scene will do the per-frame work in a fraction of a frame duration. And FWIW I cannot reproduce the issue in both demos (in Chrome on macOS). The sokol demo has a per-frame load of about 0.3ms per 8.333ms frame, and the demo hosted on vercel.app about 0.7ms, both pretty much within expecations.

3 ms·

I made my own WASM demo @ https://microui-wasm.vercel.app/ https://microui-wasm.vercel.app/ and it's only 14.6 kB compressed! Will share source code if someone

by onsclom 4mo ago

Narishma 4mo ago
Your demo seems to constantly consume 100% CPU at all times.
- onsclom 4mo ago
  Ooh interesting. What is your machine and browser? On chrome with my m1 macbook it takes less than 1ms to compute and render each frame, but I am noticing some things I can optimize from the performance flame graph! I will say, I find chrome to be way more efficient for ctx2d things than firefox or safari.
  - Narishma 4mo ago
    Firefox on Linux.
  - Lockal 4mo ago
    Chrome on Linux suffers from this too. The issues are standard for all naive immediate GUI libs: - constant repainting (while literally nothing changes) -> constant CPU load - some libs can skip repaints but have no concept of damage area - bad handling of high-dpi (which also can change dynamically) - constant repainting behaves even worse on laptops which announce 180 Hz refresh interval, which means that it drains the battery 3 times faster than 60 Hz
    - flohofwoe 4mo ago
      > - constant repainting (while literally nothing changes) -> constant CPU load This doesn't explain a 100% CPU usage since requestAnimationFrame is vsync-throttled and rendering such a simple scene will do the per-frame work in a fraction of a frame duration. And FWIW I cannot reproduce the issue in both demos (in Chrome on macOS). The sokol demo has a per-frame load of about 0.3ms per 8.333ms frame, and the demo hosted on vercel.app about 0.7ms, both pretty much within expecations.