> Totally understand the appeal and immediacy of a browser app, I was lured in by that too. For what it's worth I've reported showstopping WebCodecs issues in Chromium and there's basically no indication they'll get fixed on a predictable timeline.
Interestingly I have the exact opposite experience, I've reported issues both in the WebCodecs specification and the Chromium implementation, in all cases they were fixed within weeks. Simply though reports on public bug trackers and it wasn't really a major issue in any instance.
> Another issue I ran into that I just remembered is animating text on canvas. It's basically impossible to get pixel-perfect anti-aliased text animation using a canvas. I would have to dig up the exact details but it was something to do with how browsers handle sub-pixel positioning for canvas text, so there was always some jitter when animating. This coupled with the aforementioned WebCodecs issues led me to conclude that professional-quality video rendering is not currently possible in the browser environment. Aliasing, jitter and artifacts are immediately perceptible and are the type of thing that users have zero tolerance for (speaking from experience).
We're doing SOTA quality video rendering with WebCodecs + Chromium with millions of videos produced daily, or near SOTA if you consider subpixel AA a requirement for text. In general for pixel perfection of text, especially across different browsers and operating systems, you can't just use text elements in DOM or in canvas context, instead text needs to be rasterized to vector shapes and rendered as such.
Honestly not sure about potential jittering when animating text, but we've never had any complaints about anything regarding text animations and users are very often comparing our video exports with videos produced in Adobe AE or similar.
> Interestingly I have the exact opposite experience, I've reported issues both in the WebCodecs specification and the Chromium implementation, in all cases they were fixed within weeks. Simply though reports on public bug trackers and it wasn't really a major issue in any instance.
That's fair, they are responsive most of the time. I do have one major rendering issue in particular I've been waiting on with no movement for months, so I might be biased.
> We're doing SOTA quality video rendering with WebCodecs + Chromium with millions of videos produced daily, or near SOTA if you consider subpixel AA a requirement for text. In general for pixel perfection of text, especially across different browsers and operating systems, you can't just use text elements in DOM or in canvas context, instead text needs to be rasterized to vector shapes and rendered as such. Honestly not sure about potential jittering when animating text, but we've never had any complaints about anything regarding text animations and users are very often comparing our video exports with videos produced in Adobe AE or similar.
So you use a library that takes in text and vectorizes it to canvas shapes? That could work in theory, do you have a demo of this?
> So you use a library that takes in text and vectorizes it to canvas shapes? That could work in theory, do you have a demo of this?
Yea, it's harfbuzz compiled to WASM: https://harfbuzz.github.io/harfbuzzjs/
Then all text layout features must be implemented on top of it, like linebreaking, text align, line spacing, kerning, text direction, decoration etc.
Neat! We made a similar thing years ago in the pre-AI era, with strong focus on detection of how the planned workouts were executed rather than making plan adjustments just on a single scalar metric (e.g. TSS). Didn't really go anywhere unfortunately.
Nice! Curious, what metrics did you land on? IF, VI, duration, etc., or an interval detector? That is the unfortunate thing about the serious cyclist industry; it's tiny! Not worth pursuing as a business unless the TAM is expanded broadly
Congrats on the launch! The usage examples make a lot of sense, I'm wondering if you plan to provide preconfigured implementations for the most common checks or is custom coding the only option?
For a very similar use case I've developed custom text rendering in browser with support for CJK, Thai, Arabic (including bidirectional text with Arabic text within Latin or vice versa) and bitmap emojis.
Tbh all the complex part is handled by: https://github.com/harfbuzz/harfbuzzjs which handles the entire text shaping part (which glyphs to draw and the offset from previous glyph), then all that remains is text layout (linebreaking, kerning, line height, font size etc.) and the actual rendering ofc. Still took about 4 months of full-time work.
I looked at harfbuzzjs at one point when the work was making me cry. It looks very useful, but in the end I decided against using it. Partly because I'm keen to keep my library free of direct dependencies. But also because I know both Chromium and Firefox use Harfbuzz internally (I wonder what Safari uses instead?) and it annoys me that even with access to that tool, browsers still manage to make a mess of the Canvas Text Metrics interface[1].
People who develop canvas libraries soon learn that they don't get to play with Nice Things like consistency across browser implementations for the standards they've (allegedly) agreed to respect.
There is a well maintained Wasm build of harfbuzz: <https://github.com/harfbuzz/harfbuzzjs> with both OpenType and AAT shapers support, which should be enough but you can also provide your own shaper implementation in Wasm yes.
We're successfully using Wasm harfbuzz to render text in a web-based design tool with relatively high usage so there should be no issues integrating it :)
If you are considering upgrading from Vue 2 with Vuex note that store getters caching is not working in Vuex for Vue 3, potentially hindering performance significantly.
Interestingly I have the exact opposite experience, I've reported issues both in the WebCodecs specification and the Chromium implementation, in all cases they were fixed within weeks. Simply though reports on public bug trackers and it wasn't really a major issue in any instance.
> Another issue I ran into that I just remembered is animating text on canvas. It's basically impossible to get pixel-perfect anti-aliased text animation using a canvas. I would have to dig up the exact details but it was something to do with how browsers handle sub-pixel positioning for canvas text, so there was always some jitter when animating. This coupled with the aforementioned WebCodecs issues led me to conclude that professional-quality video rendering is not currently possible in the browser environment. Aliasing, jitter and artifacts are immediately perceptible and are the type of thing that users have zero tolerance for (speaking from experience).
We're doing SOTA quality video rendering with WebCodecs + Chromium with millions of videos produced daily, or near SOTA if you consider subpixel AA a requirement for text. In general for pixel perfection of text, especially across different browsers and operating systems, you can't just use text elements in DOM or in canvas context, instead text needs to be rasterized to vector shapes and rendered as such. Honestly not sure about potential jittering when animating text, but we've never had any complaints about anything regarding text animations and users are very often comparing our video exports with videos produced in Adobe AE or similar.
reply