6 ms·

I just tried the demo on my very capable laptop (ASUS Zephyrus G15 2021, Linux, Sway; Firefox, also tried Chromium). Performance is execrable. Text rendering i

I just tried the demo on my very capable laptop (ASUS Zephyrus G15 2021, Linux, Sway; Firefox, also tried Chromium). Performance is execrable. Text rendering is awful. Input is simply broken (e.g. my Compose key just doesn’t work). Double clicking highlighted the entire canvas thing, as well as the word under the cursor. Right clicking did nothing. Scrolling isn’t captured. The first menu thing I happened to try in the full-UI https://zetaoffice.net/demos/simple-examples/rainbow_writer.html https://zetaoffice.net/demos/simple-examples/rainbow_writer.... example (Format → Theme, maybe I just picked unfortunately) crashed the whole app (which means that it just stops working mysteriously, leaving the UI in the last state it was in). And you can’t even get started until it’s downloaded 50MB. (Though I’m actually mildly impressed it’s only that size.) Seriously, this is completely unusable. It’s “cool tech demo”, but I would hate to actually have to use it. And I’m pretty sure, based on my rather accurate understanding of how all these things work (comprehensive on the web side, good on the native side, not so much specific about LibreOffice itself), that a lot of this is going to be completely unfixable—though a couple of the things I identified are fairly straightforward to fix, which is if anything a further indictment. It’s going to be extremely hard to get even decent results without targeting real DOM instead of going pure-canvas, and you can’t get excellent results without doing so.

peutetre 2y ago
> It’s going to be extremely hard to get even decent results without targeting real DOM instead of going pure-canvas, and you can’t get excellent results without doing so. Sure you can. Google Docs switched to canvas three years ago: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-... This wasm application renders to canvas and works fine for me: https://bandysc.github.io/AvaloniaVisualBasic6/ https://bandysc.github.io/AvaloniaVisualBasic6/ This one too: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ Flutter and Google Docs gave up on the DOM because they couldn't get it working well enough, consistently enough across browsers. When you draw to canvas you get more consistent results because you control all the drawing.
- chrismorgan 2y ago
  Google Docs isn’t pure-canvas: they only switched their document area to use it for layout. Text rendering is still browser (necessary to keep performance even close), and all the rest of the UI is still DOM. Having thought extensively about it, I cannot come up with any advantage to the approach they’ve taken—neither the performance¹ nor the consistency² angles make any sense, and the product is actively worse because of it³. I’ve written more about it on HN at times, skim https://hn.algolia.com/?query=chrismorgan%20google%20docs&type=comment https://hn.algolia.com/?query=chrismorgan%20google%20docs&ty... for more. Seriously, having thought about it very carefully and reviewed the matter several times over the years, I honestly believe that they lied in their justifications. Flutter… ugh, Flutter on the web is awful awful awful awful awful AWFUL AWFUL and I will hate you if you decide with open eyes to use it when you’re deliberately targeting the web.⁴ I lack energy to express my vitriolic loathing. Just go through https://hn.algolia.com/?query=chrismorgan%20flutter&type=comment https://hn.algolia.com/?query=chrismorgan%20flutter&type=com..., there’s lots of detailed explanation of specifically what’s bad, if you need it. Avalonia Visual Basic 6? It’s the kind of thing where the limitations will show least, because of how limited it is. And also because it’s imitating (not quite the right word, but close enough) ancient software which itself wouldn’t work fully properly if run on current machines. Its text handling is dodgy, doesn’t do composition properly, scrolling is non-native, context menus are non-native which stops some things from working properly… but honestly that’s kinda the vibe they’re going for, so it’s not particularly upsetting. Pure-canvas is irredeemably bad. With difficulty you can make some things decent even with it, but excellence is impossible with pure canvas. Flutter and Google Docs did not give up on DOM for the reasons you cite. Google Docs, I honestly don’t understand why they gave up on DOM, the reasons they cited publicly genuinely don’t make sense. Flutter, it was because they don’t actually care about the web, it’s a third-class target, and too much of the way they design their API doesn’t port to DOM directly, so that making DOM a first-class citizen would have required compromises in their APIs that they were unwilling to make. But it was emphatically not about cross-browser consistency. —⁂— ¹ Seriously, Google Docs is slower than it used to be, especially with higher latency and jitter. ² The parts they replaced had no consistency problems in any realistic browsers. Seriously. Their layout requirements are, in practice, really basic. The area where consistency can actually be a problem is text shaping and rendering, but they haven’t replaced that since it would tank performance. ³ My favourite example is keyboard navigation. It doesn’t match platform conventions, and that’s really irritating. Since we’re in this thread, LibreOffice also flouts platform conventions in this area, and it’s really irritating. ⁴ If you’re focusing on mobile and make a mobile app with Flutter and also put it on the web with Flutter because why not, better than nothing, I won’t like you very much, but I’ll at least understand. But if you’re saying “we need a web thing, how about we use Flutter”… no.
andrekandre 2y ago
interesting, on my 2019 ipad pro, after initial loading that took a bit of time, editing was quite quick and fast for me* i wonder if there is some parts that remain unaccelerated or hitting performance bottlenecks on linux/firefox? * admittedly a bit low-res/ugly and hard to use on touchscreen
- thorstenb 2y ago
  Firefox is indeed a bit of a hit-and-miss these days (though we absolutely want to support it). Best experience currently is on Chrome(ium).
  - zelphirkalt 2y ago
    Any ideas why it is hit and miss? Do you test as much on FF as on Chromium based browsers, during development, as well as in quality assurance steps? I could imagine, that some devs are looking at it in Chromium (or even Chrome shudder) all day, while implementing things, and then just having to tick a checkbox for FF "Yep, seems to work.". Which would of course lead to a Chromium-centric code.
    - thorstenb 2y ago
      Most devs here use FF as their daily driver - that said, if you need to debug an emscripten-compiled c++ WASM application in the browser, then it's either printf-debugging, or Chrome + the C/C++ DevTools extension. Additionally, the overall QoI for running WASM binaries appears quite a bit better for Chrome. Both issues tip the scales currently, in favour of Chrome (sadly).
    - kolAflash 2y ago
      Being one of the ZetaOffice (and LibreOffice) hackers, I use Firefox as my primary browser. And I really don't like using software only Google knows how to support (=> Chromium). Sometimes I even think about migrating to SeaMonkey But for example, you unfortunately can't properly debug multi threaded WASM code in Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1589908 https://bugzilla.mozilla.org/show_bug.cgi?id=1589908 Have a look at the Firefox developer tools' debug tab with this page opened. And it will list the threads (web workers) named with some randomized UUID. Impossible as a daily development driver :-/ https://zetaoffice.net/demo2.html https://zetaoffice.net/demo2.html Chromium's Sources tab properly shows each thread's name. So I can easily spot "em-pthread_1" which contains the LibreOffice main thread. But have a look at this line and you'll spot some extra code I added for running in Firefox :-) https://github.com/allotropia/zetajs/blob/8258649a7b98fd6af9ef7783f59bfb75817640eb/examples/letter-address-tool/index.html#L45 https://github.com/allotropia/zetajs/blob/8258649a7b98fd6af9... If you have an idea for how to fix a Firefox specific problem, please file an issue and I promise to check if we can integrate the fix.
tjoff 2y ago
Barely worse than Teams or your typical web app. Needs polish for sure but the bar for web apps aren't exactly high. Canvas usually breaks text selections etc. and accessibility. But what they do seem to perform much better than trying to get the DOM to do something it wasn't designed for.
- chrismorgan 2y ago
  When you delve into badly-performing web apps, DOM is almost never the actual performance bottleneck. It’s other things they’re doing. And in the rare cases where DOM is the bottleneck, it’s always that they were abusing it. As for this case, I have never encountered a web app with performance (throughput and latency) problems like this. Not anywhere near it.
  - tjoff 2y ago
    Similarly I don't think canvas is the bottleneck here. Oh, and abuse is the name of the game. Almost exclusively the only thing the browser deals with is abuse. Logical consequence when the users are the one paying for it.
- zelphirkalt 2y ago
  MS Teams is among the worst pieces of software, that people have to deal with on a daily basis, because it gets shoved down their throat at their jobs. If something is even worse than that, even if "barely", then it is a complete disaster. A little "polish" will not be able to make it right.
giamma 2y ago
OnlyOffice has decent performance and is pure canvas. However, they have (or had) issues with respect to accessibility, as screen readers don't read canvas.
samiv 2y ago
"Release early, release often", isn't that the often touted wisdom? Of course that has the problem is that you can make the "first impression" only once and when that said "first impression" is terrible it can be really hard to convince anyone to try the software again for the second time. I guess releasing, almost like everything else, is a balancing game between two early or too late and both extremes have costs.
curt15 2y ago
The UI in the home page screenshot also looks like 90s-era Windows.
- exe34 2y ago
  Ooh that's great, I might give it a try.
  - rbanffy 2y ago
    I miss 1970's 3278 vibes. PROFs ftw!
- johnisgood 2y ago
  Seems like a feature. :D
yunyu 2y ago
On the flip side, this is extremely fast and works pretty well on my M1 Pro Macbook running Chrome. The only downside is that it's a little blurry (as it's rendering at 1x pixel scale).
thorstenb 2y ago
> It’s going to be extremely hard to get even decent results without targeting real DOM instead of going pure-canvas, and you can’t get excellent results without doing so. One of the ZetaOffice (and LibreOffice) hackers here - and I have to disagree. For something like an office suite, the canvas is literally the only way to achieve the document layout fidelity that users expect. The DOM does not provide enough knobs & dials to get all of MSO (and OOo) bug-for-bug layout compatibility onto the screen (and it's not even close). Don't take my word for it, see e.g. here: https://news.ycombinator.com/item?id=42100660 https://news.ycombinator.com/item?id=42100660 (and that only deals with the text layout parts).
- chrismorgan 2y ago
  Yours is a common sort of objection, but somewhere between largely and completely irrelevant and/or wrong. Somehow I fail to convey my point and what my objections are, and people assume I mean certain things that I don’t mean and didn’t think I necessarily implied. When I say “targeting real DOM”, that doesn’t mean you have to be subject to the browser’s layout implementations, though preferably you would still use its text shaping. You can still do all the layout yourself, if you want, and position everything absolutely. In practice you’ll tend to want to do at least a little of that, if you want to be able to support editing large documents; and much more if you’re aiming for consistent-across-devices layout. (… which my sister, who actually uses Word for work, reports Microsoft has been hugely slipping on—and Word never was intended as a desktop publishing platform.) View DOM as more a rendering target; I don’t mind at all. So long as you’re using real DOM for input and output, most of the problems I’m complaining about will go away. Selection, editing, context menus, text rendering, all these things will be done properly. If you take this approach, it is possible for you to run into some incompatibilities in advanced shaping, if your layout/text shaping engine and the browser’s behave differently, but in practice that will practically never happen any more in shaping, and in other areas you can control it. I would also clarify what I thought was clear enough from my initial comment’s context: when I speak of “decent results”, I refer to the editing experience, not document layout fidelity.

peutetre 2y ago

> It’s going to be extremely hard to get even decent results without targeting real DOM instead of going pure-canvas, and you can’t get excellent results without doing so. Sure you can. Google Docs switched to canvas three years ago: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-... This wasm application renders to canvas and works fine for me: https://bandysc.github.io/AvaloniaVisualBasic6/ https://bandysc.github.io/AvaloniaVisualBasic6/ This one too: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ Flutter and Google Docs gave up on the DOM because they couldn't get it working well enough, consistently enough across browsers. When you draw to canvas you get more consistent results because you control all the drawing.

chrismorgan 2y ago
Google Docs isn’t pure-canvas: they only switched their document area to use it for layout. Text rendering is still browser (necessary to keep performance even close), and all the rest of the UI is still DOM. Having thought extensively about it, I cannot come up with any advantage to the approach they’ve taken—neither the performance¹ nor the consistency² angles make any sense, and the product is actively worse because of it³. I’ve written more about it on HN at times, skim https://hn.algolia.com/?query=chrismorgan%20google%20docs&type=comment https://hn.algolia.com/?query=chrismorgan%20google%20docs&ty... for more. Seriously, having thought about it very carefully and reviewed the matter several times over the years, I honestly believe that they lied in their justifications. Flutter… ugh, Flutter on the web is awful awful awful awful awful AWFUL AWFUL and I will hate you if you decide with open eyes to use it when you’re deliberately targeting the web.⁴ I lack energy to express my vitriolic loathing. Just go through https://hn.algolia.com/?query=chrismorgan%20flutter&type=comment https://hn.algolia.com/?query=chrismorgan%20flutter&type=com..., there’s lots of detailed explanation of specifically what’s bad, if you need it. Avalonia Visual Basic 6? It’s the kind of thing where the limitations will show least, because of how limited it is. And also because it’s imitating (not quite the right word, but close enough) ancient software which itself wouldn’t work fully properly if run on current machines. Its text handling is dodgy, doesn’t do composition properly, scrolling is non-native, context menus are non-native which stops some things from working properly… but honestly that’s kinda the vibe they’re going for, so it’s not particularly upsetting. Pure-canvas is irredeemably bad. With difficulty you can make some things decent even with it, but excellence is impossible with pure canvas. Flutter and Google Docs did not give up on DOM for the reasons you cite. Google Docs, I honestly don’t understand why they gave up on DOM, the reasons they cited publicly genuinely don’t make sense. Flutter, it was because they don’t actually care about the web, it’s a third-class target, and too much of the way they design their API doesn’t port to DOM directly, so that making DOM a first-class citizen would have required compromises in their APIs that they were unwilling to make. But it was emphatically not about cross-browser consistency. —⁂— ¹ Seriously, Google Docs is slower than it used to be, especially with higher latency and jitter. ² The parts they replaced had no consistency problems in any realistic browsers. Seriously. Their layout requirements are, in practice, really basic. The area where consistency can actually be a problem is text shaping and rendering, but they haven’t replaced that since it would tank performance. ³ My favourite example is keyboard navigation. It doesn’t match platform conventions, and that’s really irritating. Since we’re in this thread, LibreOffice also flouts platform conventions in this area, and it’s really irritating. ⁴ If you’re focusing on mobile and make a mobile app with Flutter and also put it on the web with Flutter because why not, better than nothing, I won’t like you very much, but I’ll at least understand. But if you’re saying “we need a web thing, how about we use Flutter”… no.

andrekandre 2y ago

interesting, on my 2019 ipad pro, after initial loading that took a bit of time, editing was quite quick and fast for me* i wonder if there is some parts that remain unaccelerated or hitting performance bottlenecks on linux/firefox? * admittedly a bit low-res/ugly and hard to use on touchscreen

thorstenb 2y ago
Firefox is indeed a bit of a hit-and-miss these days (though we absolutely want to support it). Best experience currently is on Chrome(ium).
- zelphirkalt 2y ago
  Any ideas why it is hit and miss? Do you test as much on FF as on Chromium based browsers, during development, as well as in quality assurance steps? I could imagine, that some devs are looking at it in Chromium (or even Chrome shudder) all day, while implementing things, and then just having to tick a checkbox for FF "Yep, seems to work.". Which would of course lead to a Chromium-centric code.
  - thorstenb 2y ago
    Most devs here use FF as their daily driver - that said, if you need to debug an emscripten-compiled c++ WASM application in the browser, then it's either printf-debugging, or Chrome + the C/C++ DevTools extension. Additionally, the overall QoI for running WASM binaries appears quite a bit better for Chrome. Both issues tip the scales currently, in favour of Chrome (sadly).
  - kolAflash 2y ago
    Being one of the ZetaOffice (and LibreOffice) hackers, I use Firefox as my primary browser. And I really don't like using software only Google knows how to support (=> Chromium). Sometimes I even think about migrating to SeaMonkey But for example, you unfortunately can't properly debug multi threaded WASM code in Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1589908 https://bugzilla.mozilla.org/show_bug.cgi?id=1589908 Have a look at the Firefox developer tools' debug tab with this page opened. And it will list the threads (web workers) named with some randomized UUID. Impossible as a daily development driver :-/ https://zetaoffice.net/demo2.html https://zetaoffice.net/demo2.html Chromium's Sources tab properly shows each thread's name. So I can easily spot "em-pthread_1" which contains the LibreOffice main thread. But have a look at this line and you'll spot some extra code I added for running in Firefox :-) https://github.com/allotropia/zetajs/blob/8258649a7b98fd6af9ef7783f59bfb75817640eb/examples/letter-address-tool/index.html#L45 https://github.com/allotropia/zetajs/blob/8258649a7b98fd6af9... If you have an idea for how to fix a Firefox specific problem, please file an issue and I promise to check if we can integrate the fix.

tjoff 2y ago

Barely worse than Teams or your typical web app. Needs polish for sure but the bar for web apps aren't exactly high. Canvas usually breaks text selections etc. and accessibility. But what they do seem to perform much better than trying to get the DOM to do something it wasn't designed for.

chrismorgan 2y ago
When you delve into badly-performing web apps, DOM is almost never the actual performance bottleneck. It’s other things they’re doing. And in the rare cases where DOM is the bottleneck, it’s always that they were abusing it. As for this case, I have never encountered a web app with performance (throughput and latency) problems like this. Not anywhere near it.
- tjoff 2y ago
  Similarly I don't think canvas is the bottleneck here. Oh, and abuse is the name of the game. Almost exclusively the only thing the browser deals with is abuse. Logical consequence when the users are the one paying for it.
zelphirkalt 2y ago
MS Teams is among the worst pieces of software, that people have to deal with on a daily basis, because it gets shoved down their throat at their jobs. If something is even worse than that, even if "barely", then it is a complete disaster. A little "polish" will not be able to make it right.

giamma 2y ago

OnlyOffice has decent performance and is pure canvas. However, they have (or had) issues with respect to accessibility, as screen readers don't read canvas.

samiv 2y ago

"Release early, release often", isn't that the often touted wisdom? Of course that has the problem is that you can make the "first impression" only once and when that said "first impression" is terrible it can be really hard to convince anyone to try the software again for the second time. I guess releasing, almost like everything else, is a balancing game between two early or too late and both extremes have costs.

curt15 2y ago

The UI in the home page screenshot also looks like 90s-era Windows.

exe34 2y ago
Ooh that's great, I might give it a try.
- rbanffy 2y ago
  I miss 1970's 3278 vibes. PROFs ftw!
johnisgood 2y ago
Seems like a feature. :D

yunyu 2y ago

On the flip side, this is extremely fast and works pretty well on my M1 Pro Macbook running Chrome. The only downside is that it's a little blurry (as it's rendering at 1x pixel scale).

thorstenb 2y ago

> It’s going to be extremely hard to get even decent results without targeting real DOM instead of going pure-canvas, and you can’t get excellent results without doing so. One of the ZetaOffice (and LibreOffice) hackers here - and I have to disagree. For something like an office suite, the canvas is literally the only way to achieve the document layout fidelity that users expect. The DOM does not provide enough knobs & dials to get all of MSO (and OOo) bug-for-bug layout compatibility onto the screen (and it's not even close). Don't take my word for it, see e.g. here: https://news.ycombinator.com/item?id=42100660 https://news.ycombinator.com/item?id=42100660 (and that only deals with the text layout parts).

chrismorgan 2y ago
Yours is a common sort of objection, but somewhere between largely and completely irrelevant and/or wrong. Somehow I fail to convey my point and what my objections are, and people assume I mean certain things that I don’t mean and didn’t think I necessarily implied. When I say “targeting real DOM”, that doesn’t mean you have to be subject to the browser’s layout implementations, though preferably you would still use its text shaping. You can still do all the layout yourself, if you want, and position everything absolutely. In practice you’ll tend to want to do at least a little of that, if you want to be able to support editing large documents; and much more if you’re aiming for consistent-across-devices layout. (… which my sister, who actually uses Word for work, reports Microsoft has been hugely slipping on—and Word never was intended as a desktop publishing platform.) View DOM as more a rendering target; I don’t mind at all. So long as you’re using real DOM for input and output, most of the problems I’m complaining about will go away. Selection, editing, context menus, text rendering, all these things will be done properly. If you take this approach, it is possible for you to run into some incompatibilities in advanced shaping, if your layout/text shaping engine and the browser’s behave differently, but in practice that will practically never happen any more in shaping, and in other areas you can control it. I would also clarify what I thought was clear enough from my initial comment’s context: when I speak of “decent results”, I refer to the editing experience, not document layout fidelity.