4 ms·

Except that's just not true. It's already broken/incompatible in many places across browsers. You may not notice if you're just doing basic HTML/CSS, but if you

Except that's just not true. It's already broken/incompatible in many places across browsers. You may not notice if you're just doing basic HTML/CSS, but if you do anything slightly more dynamic, you're going to notice. An ever-expanding set of complex APIs also makes it more and more likely that bugs will go unseen and unfixed. See two examples I detailed in the blog post.

tambourine_man 4y ago
Sorry, I was reading the comments before reading your article. Getting around pointer events inconsistencies is a lot easier than building your own cross-platform VM, of course. But the project looks awesome and seems like a great initiative. I imagine there will also be differences in the way macOS, Linux and Windows handle graphics, IO, audio, etc, that will eventually leak to UVM, it's just the nature of the challenge.
- maxime_cb 4y ago
  > Getting around pointer events inconsistencies is a lot easier than building your own cross-platform VM For sure, and I did. I wrote some code that makes an invisible fullscreen div appear just at the right time to prevent pointer events being triggered when they shouldn't be #cleancode. It's just frustrating that things like that need to be done, and how often they might need to be done. > I imagine there will also be differences in the way macOS, Linux and Windows handle graphics, IO, audio, etc, that will eventually leak to UVM, it's just the nature of the challenge. At the moment you can create a window with one function call, and you have another function call to copy one frame's worth of pixels into the window. The pixel format is in BGRA byte order, 32-bits per pixel, and that's the only option. I'm going with really basic, low-level APIs like that because they're harder to get wrong. Audio is going to be equally simple. There could be cross-platform differences in things like the amount of latency to write audio, but I'll do my best to make the APIs extremely portable and hard to get wrong.

tambourine_man 4y ago

Sorry, I was reading the comments before reading your article. Getting around pointer events inconsistencies is a lot easier than building your own cross-platform VM, of course. But the project looks awesome and seems like a great initiative. I imagine there will also be differences in the way macOS, Linux and Windows handle graphics, IO, audio, etc, that will eventually leak to UVM, it's just the nature of the challenge.

maxime_cb 4y ago
> Getting around pointer events inconsistencies is a lot easier than building your own cross-platform VM For sure, and I did. I wrote some code that makes an invisible fullscreen div appear just at the right time to prevent pointer events being triggered when they shouldn't be #cleancode. It's just frustrating that things like that need to be done, and how often they might need to be done. > I imagine there will also be differences in the way macOS, Linux and Windows handle graphics, IO, audio, etc, that will eventually leak to UVM, it's just the nature of the challenge. At the moment you can create a window with one function call, and you have another function call to copy one frame's worth of pixels into the window. The pixel format is in BGRA byte order, 32-bits per pixel, and that's the only option. I'm going with really basic, low-level APIs like that because they're harder to get wrong. Audio is going to be equally simple. There could be cross-platform differences in things like the amount of latency to write audio, but I'll do my best to make the APIs extremely portable and hard to get wrong.