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 8 months ago | parent [-]

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 8 months ago | parent [-]

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.

	▲	kolAflash 8 months ago \| parent \| next [-]
		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 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 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/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.
	▲	thorstenb 8 months ago \| parent \| prev [-]
		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).