LibreOffice WASM – an Update: A status report from the journey to get LibreOffice into the browser, fully*
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Glogowski, Jan-Marek
Behrens, Thorsten
LOWA - LibreOffice WebAssembly. Most recent updates, working code, and ample stories of how we got to have LibreOffice run natively in a browser.
 Hello, everybody. Welcome to the yearly First Dem Liberal Office Represently Talk. My name is Jan-Michael Roski and my co-speaker is... Hey, everyone. Torsten Bladens, my name. Welcome also from my side to the Liberal Office WebAssembly updates. The bi-annual one looking forward to tell you lots of new things, new exciting things about WebAssembly. Let's get going. So let's start with the challenges, just a little recap of the stuff and current position we are on. What we are targeting is WebAssembly binary LibreOffice, which is usable in the browser and downloadable. Currently, the optimized version is about 150 megabytes, writer-only. You can also build the debug version, but that gets you to 200 megabytes. In the separate 12 WebAssembly file with debug information. Then we have additionally a virtual file system image to get a lot of fonts available. Currently, we simply include all the fonts that LibreOffice offers. That's another 100 megabytes. So that could be split and downloaded, but still they have to be downloaded for the user. Another thing is that WebAssembly thread pool site is currently fixed to 4 in QT. It's not really an opportunity to enlarge that. So we switched off multi-threaded document loading. And the IPC thread is also not running currently, but that's less of a problem. Then there's still with 4 gigabyte heap or RAM limit you have because of 32 bit pointers. Nothing could be done currently about this, but LibreOffice is running with 1 gigabyte. In theory, there's plenty of space for your documents. And the development and general WebAssembly development experience is still fresh. So it can be definitely be improved. So what's the current status? Basically everything is merged now in master. Also there is no static readme, a Macdon file where you can read up how to do the setup. What you can do on master is build LibreOffice now at a completely static image. So you get a large 1 gigabyte S-Office bin. And obviously you can now build S-Office HTML or slash wasm, which includes LibreOffice wasm version. And it was obviously probably the same as working with VCL demo. So that brings us to all the problems we now have fixed. The static linking is done. The core dependency loops are done with some plugin interface and G-build. Static component generation from the build directly is done. So you do not have to handle multiple dependency lists anymore for components. You can directly build the virtual file system image out of the make process. Which contains easy lists for files you want to add. And script and link time is also down to something like 30 seconds, at least for the debug build. Optimized build, which you will really want for the release because it saves you about 25% of file size. It still takes a lot of time and has huge dependencies on memory. So you just want to do that once in a while. The good thing is it's also the debug data is every time separated. So even if you build the debug image, you just need to download the 200 megabytes. And the one gigabyte debug info is downloaded by the Chrome tools to debug Dwarf in the browser. So let's have a look on the really larger open problems. First thing is the event loops are still a major problem because there are simply too many dialogues. Just grabbing for create message dialogue, which is just a message box, has something like 250 occurrences and obviously a lot of dialogues and writer needs to be ported to other stuff. There's an easy hack to create the message dialogues and you can run your normal LibreOffice with Salu system loop to emulate the M-Script behavior, which will intently crash something called Resadule. It should be quite hackable. Just look at the easy hack in Baxela. Then the other problem which did not really expect it originally is that QT is much more buggy than what we saw in the initial demos where we tested this with the Wurke's threading with the Mandelbrot stuff and it really needs more fixing. There's already an extra branch in the clone on Oli's Allotopia GitHub which has something like 20 Vazem patches mainly back ported from upstream and some work in progress stuff too from us which you need at least for the pop-up menus. But looking at the alternatives, which are not really feasible like porting GTK to Vazem, that's really the toolkit side, not the LibreOffice side which should be largely unaffected. At least if you look at QT, that changes for M-Script and the QT codes are really minimal. Then we had sort of using Colabora online frontend somehow also for WebAssembly stuff but that's not clear how that could be integrated. Maybe use some of it in the end but not as a completely different project. And then there is not so obvious way to really do a whole VCL plugin completely Vazem with abstraction and everything that will fall back on the old generic VCL rendering of widgets which is not first not nice and probably also a lot of work. So currently we are staying simply with QT and we will see what will happen. And then to finish my part of the talk, I will talk about the list of all the stuff that can generally be tackled and needs to be done in some more or less ways like uploading files, use more browser APIs, make some kind of persistence storage for the files that you download and also for the user data. So we really use the normal plugins to do translations but that's not really something that is really needed now. If we really want some IPC communication, we could implement some Unobridge. There are some ideas but it's also not needed now. And we originally expected to do some kind of peer-to-peek communication to talk between two encrypted or encrypted talk between two Vazem instances but that's also something to do after fixing Vata almost everywhere. Porting to a Vazem to a local system run time is something that would be nice but not clear what the GUI is doing there. Maybe you could port QT there too but no idea if that's at some point working. Then there is the possibility to do dynamic loading of Vazem modules and scripting but it needs more support from C-Lang and it's really not feasible currently because then you have to skip thread support which we really can't do currently and we have a long-time plan to see how good Maison can replace G-Build. We will test it back and for N-Scripten but we will see how that will work in the future. That's from my side so now Thorsten will tell you a bit about the rest of stuff and show a demo. Thanks. Okay, so let's get a bit more hands on here. What we have adopted Libro for Zwebysemly, short-hand LOVA, as Jan-Marc was pointing out and explaining the technical details, how we did that and the journey towards where we are today. All of that would not have been possible without having a project funding by NLNet and turning the EU Horizon 2020 funding for this project. And of course my company, Alotropia, also helping to further that and inspiring the development and the infrastructure and the people. Libro is in a browser. That's been the theory so far. Now let's jump into the practice. Let's take a look at the state that we have today. For that I've recorded a little demo that we will get into now in a second. Let me switch over. Okay, so let's see. What you see here is a standard Chromium back browser with Libro has been served from local hosts. Essentially you can serve that from any server in the world. It's a static binary that gets downloaded once, then it's cached and it's essentially all, every single bit is running locally. So you don't need any server beyond once getting the bits served. But it's running natively in your browser. And yeah, right now you're getting the full desktop experience. That's what you're looking at here. It's essentially Libro Office Master as it looks and feels today. There's ups and downs to that. For the demo I think it's just great because it gives you a lot of control and a lot of features. Going forward we're probably going to do something that often more of a web-like UI here. What we can see is it's blazing really fast. You've got all the features, all the layouts, all the objects, everything. You've got the sidebar, context sensitive. You can touch up everything. You can select everything. The document layouts as it would in the desktop or in the mobile version. So there's absolutely no difference. It's exactly, precisely 100% the same code and the same functionality. There's a bit of more complex table layout here. Like multi-lined columns and editing and control. A bit of undo so we go back. What you see here is some built-in image editing from Libro Office. It's also there, like again, no limits in what you can do with your content. There's absolutely nothing in terms of differences. So it's not as, for other products that you would be limited in what you can. Maybe you can see everything but you can't edit everything. Or if you can see and edit everything and you cannot insert certain things because features are missing. That is not the case. Right now lots of different draw shapes being inserted in this text document here. What's also great, you have full control over charts. So not only can you see them, you can touch them up and you can change them to your heart's content. Especially when it comes to 3D features. Pretty nice here as you can see. Switching to different types and then going 3D. All of that in a browser, all of that's going to look exactly like that in the desktop version. With the same functionality, the same feature set. Fundwork, just the same. Also quite a nice feature. Also rendering exactly as it were in the desktop version. Some little features here with shapes and text and shapes. Also no difference like you would somehow emulate the editing and then only get the busy week after a round trip on the server. Who renders it for you. No, no, it's getting processed, rendered, controlled, edited and inserted right here in your local browser. There's no lag. It's fully offline capable. So there's no need to do any round trips with any network resource. Everything, the full functionality is right here in the browser. Yes, quite some choice here in terms of extra functionality. You can access that. You can configure your user interface. Whether that makes, in general, that makes sense for quick web editing that remains to be seen. But you have the option that's always great to have options. Then you decide if you don't need that, you can disable it. But for the power users, it's all there. Quite some complex shape editing, good control. Text frames are a bit of a desk for publishing features. So that's a bit of a page on top of a page. So you can have the same editing text control that you have in a writer document also inside this frame. Again, all the features are available as they're used to for Modesta version. These 3D shapes, I'm not sure whether people, this is a widely known feature at all, but it's pretty cool. Very nice and graphic. And again, the full control is available here. All the choices, all the dialogs that you have. Yeah, it's cool to show off the features and also the speed. That's a software renderer and built into the liberal office that does that. Right. And here we are with a nice semi translucent arrow. Thanks for that. And now let's move on to a bit of an outlook. What's going to come. Thank you. Okay, so what's up next? Let's update the project plan. Obviously, we need to focus on JavaScript now with most of the groundwork done. What's up next clearly is make this nicely embeddable and work on the GUI. The desktop GUI that you've seen, and that's going to stay very likely, but just as one of the options. So what we really need and want is something much more lightweight. That also is easy to embed is this native native JavaScript. But I have that as an option. The second larger bit is as you already mentioned is we need to use much more browser APIs right now. We pay the price of shipping all those libraries that are already in the browsers like ICU, like rendering, dictionary stuff. That we really, we don't need that. So the only reason we need that is that was the fastest way to get the demo working. I really want to port that to use native JavaScript APIs. And ICU is probably the largest bit that we carry and also queued. Although that remains to be seen how much we can strip that one down. We also need to focus on getting some end-to-end encryption editing session going. We plan to do that now by summer. We tend to push this out. But we're now hopeful that we can make that with essentially everything working that we wanted to have working last year. And finally, we really want to have something like a minimum viable product out by autumn this year. So that you can already take that and that and use that for rich text editing in a real world application. Nothing much else I think is possible until then. So especially a real-time collaboration I think that's quite a bit out still for having a document and edit that and save it back. That should be doable by the autumn of this year. What to expect? So what's our vision? How do we plan to productise all of this? This is not going to be a replacement for desktop or mobile LibreOffice. If you can install LibreOffice locally on your machine and just go for it. That's more lightweight. That's probably much better platform integration than anything that runs in a browser. It's also not going to be a replacement for Collaboror Online. That's really a different product with quite different needs that it serves. For example, for excellent real-time collaboration. Instead, what the plan is, we will be serving on needs. So assume the platform is the browser. Then you might need something for touching up a letter before it goes out in your customer relationship management. Or you want to edit some templates before it's going into some background PDF production. And yes, everything works text-budget. So everything that works on the desktop that works now in the browser in terms of very, very, very complex document editing. Or let's assume your platform is the browser, but you want it to be privacy by default. Or you need end-to-end encryption. So anything that would go via a server, even if it's a server controlled by you, but most of the time you as a customer will be using a software as a server solution. And it will not be your server. Then you have a solution here that doesn't send any data ever to any server because it's all local. And you can of course run it peer-to-peer between a number of browser sessions. Or if you need massive scale for your product, but you don't have the millions of servers that you would need if there would be any server-based application. So here's something that really scales like a static website because it's just that. It's some bits that the browser needs to download initially, and then it gets cached at the edge or even in the browser. And you never pay for any cycles or any bandwidth anymore. So if you want to play with that, then you would be most welcome to look at our demo setup there. Just be aware that this is going to run Nike builds, so it might be broken. But then just check the next day. Usually we update that frequently and we see that it's running most of the time. We would also love to hear your feedback, what you think. There's going to be a Q&A session after this. But you can also reach us at any time on the contact emails from the first slide. We're also hanging out on the LibreOfficeDev IOC channel on LibreChat. We'd love to hear what you think. And also if you're interested in helping us there, hit us up. Or if you're interested in using that as a product or as part of your offering, I would be very curious to hear about that as well. Okay, thank you very much. And let's head over to Q&A. Okay, so I think we're live for the Q&A. So there were a few questions in the chat regarding the asynchronous dialogue we work. So quite a lot of that work has been done already, but there's still reams and reams of smaller dialogues that you will easily run into when you use the desktop UI. So that's quite, and it's kind of repetitive work. So there's still work to do. Then there was a question about memory profile, especially on low-end or mobile devices. Maybe Jan-Marc, something you can answer? Are you muted? Okay, so I'm taking the question then, since Jan-Marc is muted. So I'll go for it. I've already written in the chat the version we are compiling works with 1GB and 512MB is not enough. So what you're normally running is with 1GB pre-allocated memory, and it doesn't increase the memory currently. That's the version you can normally work with, and it's working fine. Okay, next question from the chat was about performance improvements. I think those were largely any kind of fixes, improvements, shedding extra sizes of the desktop version, of the LibreOffice Core version, benefits also the WebAssembly version. The Allocit specific changes are not having any direct impact on WebAssembly as of today. Then there was a question about language tool, so Java-based extensions. That's probably going to be a challenge for Marc, what do you think? Well, if I remember correctly, there's already a Java virtual machine written in WebAssembly. So you can run your Java stuff on those WebAssembly Java virtual machines, and in theory, you probably could run that stuff together, but that's some experimental stuff, I guess, for somebody who wants to spend some weeks on it. Yeah, and I think broadly, I mean, the sky's the limit, but I think probably there's enough innovation, enough stuff going on in the browser web-only arena, so that's probably something I would look first. The challenge internally is that we would probably need to get the Unibredge properly working, which we kind of sidestep right now. There's another question about Qt6. Marc, you did try that, didn't you? I did try to compile the two WebAssembly, but I gave up after two days, so in theory, it just works, because Qt5 and Qt6 backends are the same. And so they do not need any additional patches for WebAssembly, so it should work. But I just cherry-picked a few patches to our Qt5 branch from Qt6, and from what I see in the Qt6 wasm stuff, and there it's as broken as Qt5.
 Hello, everybody.  Welcome to the yearly First Dem Liberal Office Represently Talk.  My name is Jan-Michael Roski and my co-speaker is...  Hey, everyone. Torsten Bladens, my name.  Welcome also from my side to the Liberal Office WebAssembly updates.  The bi-annual one looking forward to tell you lots of new things,  new exciting things about WebAssembly.  Let's get going.  So let's start with the challenges,  just a little recap of the stuff and current position we are on.  What we are targeting is WebAssembly binary LibreOffice,  which is usable in the browser and downloadable.  Currently, the optimized version is about 150 megabytes, writer-only.  You can also build the debug version,  but that gets you to 200 megabytes.  In the separate 12 WebAssembly file with debug information.  Then we have additionally a virtual file system image  to get a lot of fonts available.  Currently, we simply include all the fonts that LibreOffice offers.  That's another 100 megabytes.  So that could be split and downloaded,  but still they have to be downloaded for the user.  Another thing is that WebAssembly thread pool site is currently fixed to 4 in QT.  It's not really an opportunity to enlarge that.  So we switched off multi-threaded document loading.  And the IPC thread is also not running currently, but that's less of a problem.  Then there's still with 4 gigabyte heap or RAM limit you have  because of 32 bit pointers.  Nothing could be done currently about this,  but LibreOffice is running with 1 gigabyte.  In theory, there's plenty of space for your documents.  And the development and general WebAssembly development experience is still fresh.  So it can be definitely be improved.  So what's the current status?  Basically everything is merged now in master.  Also there is no static readme,  a Macdon file where you can read up how to do the setup.  What you can do on master is build LibreOffice now at a completely static image.  So you get a large 1 gigabyte S-Office bin.  And obviously you can now build S-Office HTML or slash wasm,  which includes LibreOffice wasm version.  And it was obviously probably the same as working with VCL demo.  So that brings us to all the problems we now have fixed.  The static linking is done.  The core dependency loops are done with some plugin interface and G-build.  Static component generation from the build directly is done.  So you do not have to handle multiple dependency lists anymore for components.  You can directly build the virtual file system image out of the make process.  Which contains easy lists for files you want to add.  And script and link time is also down to something like 30 seconds,  at least for the debug build.  Optimized build, which you will really want for the release  because it saves you about 25% of file size.  It still takes a lot of time and has huge dependencies on memory.  So you just want to do that once in a while.  The good thing is it's also the debug data is every time separated.  So even if you build the debug image, you just need to download the 200 megabytes.  And the one gigabyte debug info is downloaded by the Chrome tools  to debug Dwarf in the browser.  So let's have a look on the really larger open problems.  First thing is the event loops are still a major problem  because there are simply too many dialogues.  Just grabbing for create message dialogue, which is just a message box,  has something like 250 occurrences and obviously a lot of dialogues  and writer needs to be ported to other stuff.  There's an easy hack to create the message dialogues  and you can run your normal LibreOffice with Salu system loop  to emulate the M-Script behavior,  which will intently crash something called Resadule.  It should be quite hackable.  Just look at the easy hack in Baxela.  Then the other problem which did not really expect it originally is that QT is much more buggy  than what we saw in the initial demos where we tested this  with the Wurke's threading with the Mandelbrot stuff and it really needs more fixing.  There's already an extra branch in the clone on Oli's Allotopia GitHub  which has something like 20 Vazem patches mainly back ported from upstream  and some work in progress stuff too from us  which you need at least for the pop-up menus.  But looking at the alternatives, which are not really feasible  like porting GTK to Vazem, that's really the toolkit side,  not the LibreOffice side which should be largely unaffected.  At least if you look at QT, that changes for M-Script and the QT codes are really minimal.  Then we had sort of using Colabora online frontend somehow also for WebAssembly stuff  but that's not clear how that could be integrated.  Maybe use some of it in the end but not as a completely different project.  And then there is not so obvious way to really do a whole VCL plugin  completely Vazem with abstraction and everything that will fall back on the  old generic VCL rendering of widgets which is not first not nice  and probably also a lot of work.  So currently we are staying simply with QT and we will see what will happen.  And then to finish my part of the talk,  I will talk about the list of all the stuff that can generally be tackled  and needs to be done in some more or less ways like uploading files,  use more browser APIs, make some kind of persistence storage  for the files that you download and also for the user data.  So we really use the normal plugins to do translations  but that's not really something that is really needed now.  If we really want some IPC communication, we could implement some Unobridge.  There are some ideas but it's also not needed now.  And we originally expected to do some kind of peer-to-peek communication  to talk between two encrypted or encrypted talk between two Vazem instances  but that's also something to do after fixing Vata almost everywhere.  Porting to a Vazem to a local system run time is something that would be nice  but not clear what the GUI is doing there.  Maybe you could port QT there too but no idea if that's at some point working.  Then there is the possibility to do dynamic loading of Vazem modules and scripting  but it needs more support from C-Lang and it's really not feasible currently  because then you have to skip thread support which we really can't do currently  and we have a long-time plan to see how good Maison can replace G-Build.  We will test it back and for N-Scripten but we will see how that will work in the future.  That's from my side so now Thorsten will tell you a bit about the rest of stuff and show a demo.  Thanks.  Okay, so let's get a bit more hands on here.  What we have adopted Libro for Zwebysemly, short-hand LOVA, as Jan-Marc was pointing out  and explaining the technical details, how we did that and the journey towards where we are today.  All of that would not have been possible without having a project funding by NLNet  and turning the EU Horizon 2020 funding for this project.  And of course my company, Alotropia, also helping to further that and inspiring the development  and the infrastructure and the people.  Libro is in a browser.  That's been the theory so far.  Now let's jump into the practice.  Let's take a look at the state that we have today.  For that I've recorded a little demo that we will get into now in a second.  Let me switch over.  Okay, so let's see.  What you see here is a standard Chromium back browser with Libro has been served from local hosts.  Essentially you can serve that from any server in the world.  It's a static binary that gets downloaded once, then it's cached and it's essentially all,  every single bit is running locally.  So you don't need any server beyond once getting the bits served.  But it's running natively in your browser.  And yeah, right now you're getting the full desktop experience.  That's what you're looking at here.  It's essentially Libro Office Master as it looks and feels today.  There's ups and downs to that.  For the demo I think it's just great because it gives you a lot of control and a lot of features.  Going forward we're probably going to do something that often more of a web-like UI here.  What we can see is it's blazing really fast.  You've got all the features, all the layouts, all the objects, everything.  You've got the sidebar, context sensitive.  You can touch up everything.  You can select everything.  The document layouts as it would in the desktop or in the mobile version.  So there's absolutely no difference.  It's exactly, precisely 100% the same code and the same functionality.  There's a bit of more complex table layout here.  Like multi-lined columns and editing and control.  A bit of undo so we go back.  What you see here is some built-in image editing from Libro Office.  It's also there, like again, no limits in what you can do with your content.  There's absolutely nothing in terms of differences.  So it's not as, for other products that you would be limited in what you can.  Maybe you can see everything but you can't edit everything.  Or if you can see and edit everything and you cannot insert certain things because features are missing.  That is not the case.  Right now lots of different draw shapes being inserted in this text document here.  What's also great, you have full control over charts.  So not only can you see them, you can touch them up and you can change them to your heart's content.  Especially when it comes to 3D features.  Pretty nice here as you can see.  Switching to different types and then going 3D.  All of that in a browser, all of that's going to look exactly like that in the desktop version.  With the same functionality, the same feature set.  Fundwork, just the same.  Also quite a nice feature.  Also rendering exactly as it were in the desktop version.  Some little features here with shapes and text and shapes.  Also no difference like you would somehow emulate the editing and then only get the busy week after a round trip on the server.  Who renders it for you.  No, no, it's getting processed, rendered, controlled, edited and inserted right here in your local browser.  There's no lag.  It's fully offline capable.  So there's no need to do any round trips with any network resource.  Everything, the full functionality is right here in the browser.  Yes, quite some choice here in terms of extra functionality.  You can access that.  You can configure your user interface.  Whether that makes, in general, that makes sense for quick web editing that remains to be seen.  But you have the option that's always great to have options.  Then you decide if you don't need that, you can disable it.  But for the power users, it's all there.  Quite some complex shape editing, good control.  Text frames are a bit of a desk for publishing features.  So that's a bit of a page on top of a page.  So you can have the same editing text control that you have in a writer document also inside this frame.  Again, all the features are available as they're used to for Modesta version.  These 3D shapes, I'm not sure whether people, this is a widely known feature at all, but it's pretty cool.  Very nice and graphic.  And again, the full control is available here.  All the choices, all the dialogs that you have.  Yeah, it's cool to show off the features and also the speed.  That's a software renderer and built into the liberal office that does that.  Right.  And here we are with a nice semi translucent arrow.  Thanks for that.  And now let's move on to a bit of an outlook.  What's going to come.  Thank you.  Okay, so what's up next?  Let's update the project plan.  Obviously, we need to focus on JavaScript now with most of the groundwork done.  What's up next clearly is make this nicely embeddable and work on the GUI.  The desktop GUI that you've seen, and that's going to stay very likely, but just as one of the options.  So what we really need and want is something much more lightweight.  That also is easy to embed is this native native JavaScript.  But I have that as an option.  The second larger bit is as you already mentioned is we need to use much more browser APIs right now.  We pay the price of shipping all those libraries that are already in the browsers like ICU, like rendering, dictionary stuff.  That we really, we don't need that.  So the only reason we need that is that was the fastest way to get the demo working.  I really want to port that to use native JavaScript APIs.  And ICU is probably the largest bit that we carry and also queued.  Although that remains to be seen how much we can strip that one down.  We also need to focus on getting some end-to-end encryption editing session going.  We plan to do that now by summer.  We tend to push this out.  But we're now hopeful that we can make that with essentially everything working that we wanted to have working last year.  And finally, we really want to have something like a minimum viable product out by autumn this year.  So that you can already take that and that and use that for rich text editing in a real world application.  Nothing much else I think is possible until then.  So especially a real-time collaboration I think that's quite a bit out still for having a document and edit that and save it back.  That should be doable by the autumn of this year.  What to expect?  So what's our vision?  How do we plan to productise all of this?  This is not going to be a replacement for desktop or mobile LibreOffice.  If you can install LibreOffice locally on your machine and just go for it.  That's more lightweight.  That's probably much better platform integration than anything that runs in a browser.  It's also not going to be a replacement for Collaboror Online.  That's really a different product with quite different needs that it serves.  For example, for excellent real-time collaboration.  Instead, what the plan is, we will be serving on needs.  So assume the platform is the browser.  Then you might need something for touching up a letter before it goes out in your customer relationship management.  Or you want to edit some templates before it's going into some background PDF production.  And yes, everything works text-budget.  So everything that works on the desktop that works now in the browser  in terms of very, very, very complex document editing.  Or let's assume your platform is the browser, but you want it to be privacy by default.  Or you need end-to-end encryption.  So anything that would go via a server, even if it's a server controlled by you,  but most of the time you as a customer will be using a software as a server solution.  And it will not be your server.  Then you have a solution here that doesn't send any data ever to any server because it's all local.  And you can of course run it peer-to-peer between a number of browser sessions.  Or if you need massive scale for your product, but you don't have the millions of servers that you would need  if there would be any server-based application.  So here's something that really scales like a static website because it's just that.  It's some bits that the browser needs to download initially,  and then it gets cached at the edge or even in the browser.  And you never pay for any cycles or any bandwidth anymore.  So if you want to play with that, then you would be most welcome to look at our demo setup there.  Just be aware that this is going to run Nike builds, so it might be broken.  But then just check the next day.  Usually we update that frequently and we see that it's running most of the time.  We would also love to hear your feedback, what you think.  There's going to be a Q&A session after this.  But you can also reach us at any time on the contact emails from the first slide.  We're also hanging out on the LibreOfficeDev IOC channel on LibreChat.  We'd love to hear what you think.  And also if you're interested in helping us there, hit us up.  Or if you're interested in using that as a product or as part of your offering,  I would be very curious to hear about that as well.  Okay, thank you very much.  And let's head over to Q&A.  Okay, so I think we're live for the Q&A.  So there were a few questions in the chat regarding the asynchronous dialogue we work.  So quite a lot of that work has been done already,  but there's still reams and reams of smaller dialogues that you will easily run into  when you use the desktop UI.  So that's quite, and it's kind of repetitive work.  So there's still work to do.  Then there was a question about memory profile, especially on low-end or mobile devices.  Maybe Jan-Marc, something you can answer?  Are you muted?  Okay, so I'm taking the question then, since Jan-Marc is muted.  So I'll go for it.  I've already written in the chat the version we are compiling works with 1GB and 512MB is not enough.  So what you're normally running is with 1GB pre-allocated memory,  and it doesn't increase the memory currently.  That's the version you can normally work with, and it's working fine.  Okay, next question from the chat was about performance improvements.  I think those were largely any kind of fixes, improvements, shedding extra sizes of the desktop version,  of the LibreOffice Core version, benefits also the WebAssembly version.  The Allocit specific changes are not having any direct impact on WebAssembly as of today.  Then there was a question about language tool, so Java-based extensions.  That's probably going to be a challenge for Marc, what do you think?  Well, if I remember correctly, there's already a Java virtual machine written in WebAssembly.  So you can run your Java stuff on those WebAssembly Java virtual machines,  and in theory, you probably could run that stuff together,  but that's some experimental stuff, I guess, for somebody who wants to spend some weeks on it.  Yeah, and I think broadly, I mean, the sky's the limit,  but I think probably there's enough innovation,  enough stuff going on in the browser web-only arena,  so that's probably something I would look first.  The challenge internally is that we would probably need to get the Unibredge properly working,  which we kind of sidestep right now.  There's another question about Qt6.  Marc, you did try that, didn't you?  I did try to compile the two WebAssembly, but I gave up after two days,  so in theory, it just works, because Qt5 and Qt6 backends are the same.  And so they do not need any additional patches for WebAssembly, so it should work.  But I just cherry-picked a few patches to our Qt5 branch from Qt6,  and from what I see in the Qt6 wasm stuff, and there it's as broken as Qt5.
lotech_lowa_0_155.png lotech_lowa_156_16259.png lotech_lowa_16260_18263.png lotech_lowa_18264_18983.png lotech_lowa_18984_19223.png lotech_lowa_19224_19331.png lotech_lowa_19332_19463.png lotech_lowa_19464_19559.png lotech_lowa_19560_19631.png lotech_lowa_19632_19691.png lotech_lowa_19692_19739.png lotech_lowa_19740_19787.png lotech_lowa_19788_19835.png lotech_lowa_19836_19895.png lotech_lowa_19896_19955.png lotech_lowa_19956_20015.png lotech_lowa_20016_20123.png lotech_lowa_20124_21515.png lotech_lowa_21516_22283.png lotech_lowa_22284_22343.png lotech_lowa_22344_22535.png lotech_lowa_22536_22895.png lotech_lowa_22896_23171.png lotech_lowa_23172_24011.png lotech_lowa_24012_25055.png lotech_lowa_25056_25283.png lotech_lowa_25284_25427.png lotech_lowa_25428_25955.png lotech_lowa_25956_26075.png lotech_lowa_26076_26123.png lotech_lowa_26124_26291.png lotech_lowa_26292_26603.png lotech_lowa_26604_26651.png lotech_lowa_26652_26711.png lotech_lowa_26712_26795.png lotech_lowa_26796_26843.png lotech_lowa_26844_26987.png lotech_lowa_26988_37595.png lotech_lowa_37596_39059.png lotech_lowa_39060_41879.png lotech_lowa_41880_42719.png lotech_lowa_42720_43571.png lotech_lowa_43572_43728.png