It is always an exciting time to see freshly minted ARM based silicon arriving in the form of Apple’s massive shift to the ARM based M1. This of course means work for Collabora’s LibreOffice team too. The code needs to be prepared for M1, step by step. Here we update you on the status of the work, and what needs to be done.
With the launch of the new Apple devices nearing, it is important that suitable software arrives around the same time as new hardware. Apple ensures this by a translation layer, so that software for Intel Macs can be used, using Rosetta translation.
Nevertheless, given the code size of LibreOffice, for the best performance it makes most sense to have a pre-optimized native binary. As such Collabora joined the Universal App Quickstart Programme back in July and has been doing work on enabling LibreOffice for M1 since then.
This effort is made possible by the kind support of those who buy LibreOffice Vanilla in the Mac app store. Thank you! And thanks too to Tor Lillqvist for his patience and hard work here.
The status of the work
All of these changes are in master, or in the gerrit queue getting past our CI automation:
Configuration changes (mostly there). It should now possible to configure and build a native LibreOffice on a Apple Silicon, as well as cross-compiling to x86_64.
Patching and fixing of lots of bundled libraries to make them build cleanly.
Then there is a first attempt at a new C++/UNO ABI bridge – we need to match Apple’s ABI by tweaking Linux’s ARM64 support to match. This allows UNO scripting to work (in theory).
We still have some failing unit tests, that need investigation, as well as some other bits, described below.
All of this means that LibreOffice should start and work on M1! So far it has had only very basic Writer & Calc testing. The more exciting, complex features are not yet tested.
What’s next .. want to get involved?
Post-launch, if you can get an M1 Mac, then help is always most welcome! We have several missing pieces that will require further work, with some unusual low-level bits.
The new C++/UNO ABI bridge requires more testing, to ensure the UNO scripting support works smoothly.
Enabling bits we didn’t compile in yet: Firebird, Java (when there is a JDK).
Scripts to combine builds for arm64 and x86_64 into one universal app (i.e. one where binaries are “fat,” consisting of separate parts for each architecture)
Adaptation to whatever new checks are added for universal apps in the App Store. This is an ongoing unpredictable part of our work: adapting 8 million lines of code to the latest updated rules, keeping our builds compiling and signing with the latest tool chains.
Of course we’ll continue to work to bring the best LibreOffice possible to Apple Silicon as time permits, and we are confident that even if we don’t make it in the next month or two, Rosetta 2 will fill the gap using dynamic instruction set translation. And when all is done, our open source desktop productivity tools will benefit the full power of the new Macs!
Autumn is just around the corner. For many participants in the GSoC 2020, a busy and instructive summer full of hacking on open source projects came to an end a few weeks ago. Commits have been contributed and final reports have been written. This year experienced Collabora Productivity developers were again mentors for various projects of the Google Summer of Code for the LibreOffice project. Here are some examples of projects our team helped to succeed!
Analysing Writer documents with the “Style Inspector”
The “Style Inspector” is a great new tool. You can access it through a new icon (an eye combined with a pencil) in the Sidebar (also via “Sidebar Settings”). The Style Inspector displays in full detail (and hierarchical) all styles and also direct formatting applied to a cursor position in a Writer document. So you can analyse, identify problems and clean them up. Sometimes formatting in documents is messy and people mix styles with direct formatting. The Style Inspector allows you to see that.
The feature is available for testing in pre-released development versions of LibreOffice. Shivan Kumar Singh picked up the proposal from the LibreOffice Design Team. He was mentored by Collaborans TomažVajngerl and MikeKaganski with Heiko Tietze from the LibreOffice Design Team. Take a look into Singh’s final report! It is an inspiring a guide on how to approach a big project like LibreOffice.
Improving the way to find and add extensions
There are many useful extensions to LibreOffice and users should be able to find them easily! Like in app stores like Gnome Software or the Play Store. That is basic idea behind “Tight Integrations” and the proposal from the LibreOffice design team. Yusuf Keten made this his GSOC project a success and added the possibility to search and sort the through extensions without having to leave LibreOffice. You start this new way to search with a clear yellow star with a download arrow, that is in the templates dialog, at the icons in the view options, or from the galleries pane in the side bar.
If you are curios about this handy extensions feature you can already test and find it in the latest LibreOffice pre-releases. Yusuf was mentored ba Collabora’s Muhammet Kara and Heiko Tietze from the LibreOffice design team. Find all the details of Yusuf’s work in his final report.
“I learned a lot of things during the GSoC. Although GSoC is finished, I will continue to contribute to LibreOffice. I am very happy to be part of the LibreOffice community.” (Yusuf Keten)
Changing the contour – shadows are becoming blurry
Did you know, that in LibreOffice the shadows are just a copy of the object? There are already a lot of settings to change their appearance, like its colour, its angle, the transparency and distance behind the object. Mentored by Collaboran’s TomažVajngerl and Miklos Vajna, Ahmad Ganzouri added another option. The “Blurry Shadows” make use of the already implemented BitmapFilterStackBlur and make the shape of the shadow look very realistic. Find the details around the development in Ahmad’s final report. We have seen the Blurry Shadow option in the master branch and expect it to be available to all users in Version 7.1 of LibreOffice. The option can be easily accessed via the “Area” dialog in “Objects & Shapes” or directly via the corresponding Sidebar module.
Searching for a mentor? Join us GitHub!
Google Summers of Code are an excellent opportunity to learn working in many open source projects. But where to find mentors during the rest of the year? We recently moved the code of Collabora Online to GitHub. You will find a growing community there, with easy hacks to get started. Community Mentor Muhammet Kara and the rest of our team of open source developers are there and willing to share their vast experience.
From Thursday, 15th to Saturday 18th 2020 the openSUSE & LibreOffice Conference takes place as a virtual and joint event. We are glad to be one of the sponsors and to be able to contribute no less than 14 talks from our team members. To make it easier for you to keep track of all the topics, we have prepared a little overview of our talks. See you in the livestream!
Accelerating the adoption of Open Source! How does Collabora do that together with their partners and customers? About another year of investment into LibreOffice alongside the community, the ecosystem and our choices. #Collabora #EcosystemRead more!
Bringing the Sidebars Online
12:30 UTC, Ashod Nakashian
Adding the Sidebars, with the rich and advanced editing features, to Online was challenging. Learn, how we succeeded! #OnlineUIRead more!
Bringing the NotebookBar to Online
13:30 UTC, Szymon Kłos
The story behind introducing new (optional) user interface for Online. Learn about the milestones of this new feature sponsored by Collabora. #OnlineUIRead more!
Implementing Vulkan-capable drawing using the Skia library
14:00 UTC, Luboš Luňák
Skia is a unified modern drawing across all platforms, so this is about the nice visual performance of LibreOffice and Collabora products. How is the implementation going? #LibreOfficeDevRead more!
Making Online trivial to setup
15:30 UTC, Muhammet Kara
We have recently released a big step in improving Collabora (thus LibreOffice) Online and lowered the barrier to liberating the documents of home-users. This is a quick presentation shows how the one-click installation app for Online works, and where we are at now. #OnlineInstallationRead more!
Day 2, Friday 16th 2020
Faster Jail Creation with Bind-Mount
11:00 UTC, Ashod Nakashian
A jail is an essential part of the secure work and collaborating in Collabora Online. Learn about the design and challenges of setting up jails… fast! #OnlineDevRead more!
OOXML / PDF Digital Signing in Draw and elsewhere
11:30 UTC, Miklos Vajna
LibreOffice did have support for digital signing for ODF files. Collabora extended this to OOXML files and to signing existing PDF files. Come and see where we are, what still needs to be done, and how you can help. #DigitalSigningRead more!
Come and hear some of the stories of the beginning, and before the beginning. Hear a developer’s perspective on the first ten years of the project and how companies had to do with this, alongside amazing volunteers. #LibreOfficeRead more!
Chrome OS as a new platform
16:00 UTC, Jan Holesovsky
Hear about the Chrome OS and the work we have made to enable the Collabora Office Android app for easy consumption on Chromebooks. #MobileRead more!
Improvements to PDF support in Collabora Online
18:00 UTC, Tomaž Vajngerl
Recently we added possibility to open PDFs with Collabora Online, which opens the PDF in Draw as a series of embedded PDF graphics (each one in its own page). In this talk, hear about additional improvements to the PDF functionality – like searching and handling of PDF annotations. #PDFRead more!
Day 3, Saturday 17th 2020
History of Online & Mobile
12:00 UTC, Jan Holesovsky
Come and hear about the history of Collabora Online, LibreOfficeKit, Leaflet and other building bits that led to the Online as we know today. #MobileRead more!
Re-using the Sidebar on phones
12:30 UTC, Szymon Kłos
The talk about work done by Collabora Productivity for improving UX on mobile phones. Editing on smartphones has never been easier. Hear some technical details in this talk. #Mobile #OnlineUIRead more!
in PT/ES. For users it is most important that UI elements are easy to recognize. Hear about improvements that have been made on that front in Collabora Online. #OnlineUI #CSSLeia mais!
How to become a part of this
Very easily. The attendance openSUSE and LibreOffice conference 2020 is free of charge. Just subscribe to the conference website, meet the community and join three days of discussion about the latest developments with regard to LibreOffice and openSUSE. The complete schedule of the virtual conference is here at your disposal.
Right after celebrating a great LibreOffice 10th Anniversary, we are delighted to present the 2020-version of our LibreOffice growth infoGraphic, including beautiful visuals and interesting numbers! We do hope you appreciate it and would love to hear your feedback. And of course it is great if you find the format, in which it is presented, convenient to share.
Many numbers are again up. Our devs are top code contributors to LibreOffice with 7518 code commits. And the popular “Collabora Online Development Edition” (CODE), for home use & small teams (find details here), has over 50 million Docker image pulls! We are extremely grateful for all partners and customers working with us to make this possible.
Soon there will be the LibreOffice Conference 2020 (October 14 to October 16), where you can meet developers, including of course our developers, and other contributors from the community, and attend the online sessions of the talks of our developers.
So.. check out the updated LibreOffice growth infoGraphic on 2020 here:
This work by Collabora Productivity was possible thanks to AMD.
LibreOffice 7.0, just released, includes a new drawing backend based on the Skia library, which allows LibreOffice to use the modern Vulkan API to graphics operations. This Visual Class Library (VCL) backend is the default on the Windows platform, superseding the OpenGL-based backend.
Working on the future of graphics for office productivity
Having multiple VCL backends has its benefit to integrate with different operating systems, but each backend performing its own rendering implementation is far from optimal, since we cannot add new rendering functionality and assume that it will work cross-platform. Many backends across different platforms and toolkits miss optimized paths for various rendering tasks. This adds complexity and makes it hard to ensure that rendering objects happens in an accelerated way everywhere.
Another problem is that multiple backends regularly perform the same type of mapping from VCL’s APIs to what a modern toolkit provides these days. This duplication means not only maintenance cost, but also can lead to having to fix the same bug at multiple places.
Moving away from GDI and OpenGL
The VCL library is responsible for widgets (buttons, controls, etc.) and basic rendering. It does not implement the drawing directly, but it provides an internal API, which is implemented by various backends that implement the actual graphics operations. These backends usually adapt LibreOffice to each platform , for example the ‘win’ backend is used on Windows, the ‘kf5’ and ‘gtk3’ backends are for Unix-like platforms using the KDE Frameworks and the Gtk3 graphics toolkit respectively and there is a ‘headless’ backend used by tests that does not render to the screen.
Each VCL backend uses an underlying graphics API available on the platform to perform the graphics operations. The Cairo library is used by some Unix-like and ‘headless’ backends, the ‘osx’ backend uses the macOS Quartz. On Windows, the ‘win’ backend has several plugable drawing implementations:
GDI drawing. This code is relatively old and has several limitations, such as not being double-buffered.
OpenGL drawing. This code provides GPU-accelerated drawing. OpenGL is used directly, so all relevant code including OpenGL shaders needed to be implemented in LibreOffice. The OpenGL API is also slowly being phased out in the industry.
Skia drawing. The Skia library hides implementation details, and provides several rendering methods, including Vulkan API.
Integrating Skia and Vulkan
The Skia library is not shipped in a binary form, not even by 3rd-party providers such as Linux distributions. It is provided only as source and the usual way to use it in a project is to ship it with that project. LibreOffice includes Skia as a 3rd-party library and fortunately building it using the LibreOffice gbuild system is reasonably simple. An additional complication is that Skia provides a new release roughly every 6 weeks, and generally only the latest release receives any fixes, requiring repeated updates. Since Skia is continually evolving, each update may also require adjustments (although so far it seems they are generally small).
Collabora’s developers taking the first hurdles
The Skia API is generally well documented, but it appears to be mostly aimed at developers already working on a project using Skia, such as Chrome. Important classes have their API well described, but it can be difficult to find tutorials for them and some classes are harder to understand at the beginning (for example, SkPixmap, SkBitmap, SkImage and SkSurface are all classes representing a drawable, but it was unclear at the beginning what the suitable use cases would be for each for them).
Similarly, it is not obvious how to use Skia in a new project. There does not seem to be any actual developer introduction to Skia in the documentation, nor does thereseem to be any documentation on how to setup a new or standalone project using Skia. There is a Hello-World example in the examples/ directory that is based on platform integration code that is not part of the Skia library itself but is inside a sk_app/ directory in the tools/ directory. That code was usable for LibreOffice, but required patching to cover LibreOffice needs (for example, the code created a new graphics context for each toplevel window, and Skia requires proper graphic context to be used in drawing operations, but LibreOffice code sometimes does not know which toplevel window will use the result of a drawing).
LibreOffice is a fairly old codebase, and still uses relatively old concepts such as paletted bitmaps, low-resolution bitmaps (such as 4bpp) or drawing that uses the XOR operation on pixels. Skia, being a relatively new library, has features that assume modern concepts are used (for example, RGB bitmaps are required to be 32bpp with unused alpha channel, 24bpp RGB bitmaps are not supported).
Once the initial learning period is over, Skia is consistent in its API and reasonable flexible to use allowing progress to be relatively fast. Code using Skia is very readable, and using Skia makes future maintainance tasks easier to perform. Even some old concepts, such as LibreOffice using a separate bitmap for alpha channel, sometimes interpreted as 8bpp and sometimes as alpha, later blended with data bitmap to get the actual result, could be mostly implemented using Skia API, making them GPU-accelerated.
Nice performance and even room for improving
While there were some concerns about how performance would be affected by moving to Skia compared to OpenGL driver and and hardware implementations that have been heavily optimized over the past several decades, it turns out that performance within LibreOffice is at least equivalent to the OpenGL version and synthetic benchmarks show that there is room for improvement.
Benefits for LibreOffice-technology
While somewhat complicated at the beginning, using Skia in LibreOffice has been in general a rather pleasant experience. In the future LibreOffice’s use of Skia could be extended to other platforms, reducing the number of platform rendering APIs used, eliminating duplicated code, reducing bug count and generally improving quality.
For comparison, LibreOffice OpenGL drawing code is roughly 12k lines of code, while Skia drawing code is only 4k.
Apart from the immediate benefits, moving to Skia and Vulkan on Windows paves the way for a single, powerful, hardware-accelerated rendering API cross-platform.
Moving to Skia on Windows required about 7 person-months ol, which lets us use Vulkan acceleration without large implementation costs. It will be interesting to see how much time is saved in the next few years from the reduced maintenance cost. The resulting work is mature enough that there is no real negative change in performance, and we have not started heavily optimizing yet.