Live data from Hacker News

LibreOffice running natively in the browser via WebAssembly

lab.allotropia.de

131–140 of 216 posts

Re: LibreOffice running natively in the browser via WebAssembly

#131
post #12

Earlier quoted context omitted.

Even with a fast connection, it takes a very long time. I'm guessing the site is overloaded as the peak was a few tens of Mb/s, and generally much slower.

Does make you wonder what other optimization can be done. Maybe the whole thing doesn't have to be loaded in immediately.

Such lazy loading might be difficult to retrofit into an application designed for an environment where it can load a lot from disk to RAM quickly and has never (IME) been well design in terms of such resource use.

Some lazy loading could probably be done relatively easily where OO does on-demand load libraries, but that would significantly resource apparent in-use performance if truly done live so you'd want to background load the optional parts once the immediately needed ones are done.

I'm guessing that this is a straight compile to WASM with the minimal changes needed to things that would otherwise break completely in the different environment.

Re: LibreOffice running natively in the browser via WebAssembly

#132
post #119

Earlier quoted context omitted.

Longer-term, we need to move to browser-native GUI, yep. The nice bits though - the entire document loading, rendering & editing works in the browser now.

What that means though? A VCL backend that targets HMTL5 instead of Qt? Can you elaborate?

We already use cairo/freetype/skia to do essentially all the document rendering in software (not for the Qt prototype though), so that's not a big leap to get that blitted out.

Incrementally then using more of html canvas to speed things up might be next.

Most of the work is going to be having the GUI (toolbar/notebook bar, menues, sidebar, dialogs) browser-native of course.

Re: LibreOffice running natively in the browser via WebAssembly

#135

Earlier quoted context omitted.

300 MiB. & … "a bit" — it takes nearly 20 seconds on "Gigabit" fiber. (312 MiB in 19.22s, or 136 Mbps.) Runs shockingly smoothly once it starts, though.

> Runs shockingly smoothly once it starts, though. On what hardware? I've got a 2019 MacBook Pro with i9 and 32 GB of RAM, and there's a noticable delay (I'd guess 200~400-ish miliseconds) when clicking any elements with Firefox or Chrome.

Works fine on my current work windows laptop, 16gb ram with some budget low electricity use processor.

Probably just apple not supporting anything web related as usual.

Re: LibreOffice running natively in the browser via WebAssembly

#136
I don't have time to do a more complete check, but am I wrong in assuming that all of these demos still have basically non-existant accessibility? Last time I looked Qt was still trying to pretend that was the browser's fault. As far as I can tell this seems to still be pushing out blobs of pixels to the canvas.

Seems really laggy for me on a 2015 Mac, to the point where I got a few unresponsive page warnings, but resizing at least works, so that's starting to get better. WASM continues to be very impressive/promising, and there's a lot of potential here. I just wish more of these frameworks would leverage the rest of the browser properly.

Re: LibreOffice running natively in the browser via WebAssembly

#138
post #129

Earlier quoted context omitted.

I meant Electron brought webapps to the Desktop. Now Web Assembly seems to bring native apps to the browser.

So the next step would be to write "electron-browserify.js" which emulates a JS runtime in browser so you can run Electron apps remote.

I'm sure there's a relevant XKCD somewhere.

Re: LibreOffice running natively in the browser via WebAssembly

#139
post #119

Earlier quoted context omitted.

What that means though? A VCL backend that targets HMTL5 instead of Qt? Can you elaborate?

We already use cairo/freetype/skia to do essentially all the document rendering in software (not for the Qt prototype though), so that's not a big leap to get that blitted out. Incrementally then using more of html canvas to speed things up might be next. Most of the work is going to be having the GUI (toolbar/notebook bar, menues, sidebar, dialogs) browser-native of course.

I’ve been seriously impressed with Tokamak for Swift. Is this what you mean for browser native GUI?

https://github.com/TokamakUI/Tokamak

Re: LibreOffice running natively in the browser via WebAssembly

#140

Had to try Bromite to get it working well, but I'm seriously impressed by how fast this is on mobile (Snapdragon 855). Everything just seems to work, except the mobile keyboard because the browser doesn't know what to do with it or when to show it. If it works on my phone, this should run great on most modern flagships to the point of it almost being usable! Quite an impressive feat to compile a complex program like…

> Had to try Bromite to get it working well, but I'm seriously impressed by how fast this is on mobile (Snapdragon 855).

This is so interesting. I tried on my phone, oneplus 8 pro, snapdragon 865 so a little bit above and on a scale that does 1-10 where 1 is "not even in dreams" and 10 is "more-or-less tolerable" I'd rate it a 2 or 3. There's an ostensible slowness when just selecting text for instance. If for you this is fast I don't think you have any idea of how fast an actually fast computer can be and that makes me super sad for you !

Post reply on HN