I was quite curious how LibreOffice-5.2 would perform with all the OpenGL/VCL tuning that happend in the past months. Unfourtunatly, the UI still feels quite "laggy" compared to the originaly X11 backend, despite the leading-edge driver stack (mesa-12.0 on intel haswell). Other 2D programs which use OpenGL for rendering (Firefox, Chrome, Java) do not exhibit such performance issues, in fact both perform better with OpenGL enabled compared to their X11/Xrender backends. Fortunately, the intel driver provides ways to debug unexpected low performance by setting the environment variable INTEL_DEBUG=perf. This is what I get: Quite a lot of messages like: GTT mapping a busy miptree BO stalled and took 20.366 ms. Some shaders seem to fail at compilation stage: SIMD16 shader failed to compile: FS compile failed: Failure to register allocate. Reduce number of live scalar values to avoid this. Unsupported form of variable indexing in FS; falling back to very inefficient code generation Cycling through the main menu seems to force endless shader re-compilation, I soon end up with hundreds of compiled shaders: Recompiling fragment shader for program 802 multisampled FBO 0->1 function is no-op Recompiling fragment shader for program 805 multisampled FBO 0->1 PS: Furthermore sub-pixel AA does not work when OpenGL is enabled (should I file a separate report about this?).
Tomaž: knowing your work on including OpenGL part on LO, thought you might be interested in this one.
Clemens: would you like to join the QA team? https://wiki.documentfoundation.org/QA You will find us on IRC: https://wiki.documentfoundation.org/QA/IRC
Thanks for the offer, however currently I am too busy to contribute anything meaningful. Hopefully next year I'll have more spare-time...
Still there with LibreOffice-6 running on radeonsi (mesa 17.2.4). This is *really* concerning, keeping in mind radeonsi is one of the most capable open-source opengl-drivers and capable of running most AA titles on linux without issues (also the Java2D OpenGL pipeline, as well as Mozilla Firefox's WebRender and OpenGL backend, as well as Google Skia work really well). So only LibreOffice' OpenGL backend is causing problems, leading to horrible performance.
Linux OpenGL backend doesn't have glyph caching so it is currently slow and implementing that is not that trivial (mainly rendering glyph to texture with FT is missing) but not too hard either, I just don't have the time to implement that. Also most of the problems of getting super-fast OpenGL rendering aren't related to OpenGL backend at all, but how we do rendering in principle (scenegraph) in LO and this is not something we can change overnight.
Hi Tomaz, > Linux OpenGL backend doesn't have glyph caching so it is currently slow and implementing > that is not that trivial (mainly rendering glyph to texture with FT is missing) but not too hard either, > I just don't have the time to implement that. Thanks for your answer, this also explains why I see most time spent in various types of memcpy when working with spreadsheets containing a lot of text. When I tried to run earlier versions of the OpenGL backend on my Intel-HD (OpenGL-2.1) I also saw a lot of shader recalculations and other performance problems reported by the intel driver (with INTEL_DEBUG=perf). This makes me wonder ... would it make sense to apply for Google-Summer-of-Code with the intention of bringing the OpenGL backend on Linux to a production-ready state (so that it can be enabled on linux by default), by: * Implement the missing glyph-cache - including subpixel antialiasing (requires GL_NV_texture_barrier or readback for proper blending) * Test and tune for various driver/hw combinations out there (r600, radeonsi, nouveau, nvidia proprietary, i965) and - resolve bottlenecks (shader recompilations, other expensive state changes, texture upload) - extend the white/black lists - profile typical API interations between LibreOffice and VCL and tune the backend so that common cases hit driver fast paths. - extend the use of shaders where approriate LibreOffice always had a rather sluggsih UI on Linux especially when working with documents that contain images, so it would be great if that could be finally solved. I know layering a typical immediate-drawing-API on top of OpenGL won't magically make everything super-fast, but I hope it will improve the average feel and responsiveness.
(In reply to Clemens Eisserer from comment #6) > This makes me wonder ... would it make sense to apply for > Google-Summer-of-Code with the intention of bringing the OpenGL > backend on Linux to a production-ready state You mean you personally would apply as a student?
If I understand correctly comment #5, this bug report is confirmed but should be seen as an enhancement. Feel free to change what should be if I am wrong. Best regards. JBF
As Skia with Vulkan will replace OpenGL UI rendering on all platforms, it does not make sense to keep OpenGL UI reports open. Details about Skia: https://www.collaboraoffice.com/success-story/implementing-vulkan-capable-libreoffice-user-interface-using-the-skia-library/
(In reply to Buovjaga from comment #9) > As Skia with Vulkan will replace OpenGL UI rendering on all platforms, it > does not make sense to keep OpenGL UI reports open. > > Details about Skia: > https://www.collaboraoffice.com/success-story/implementing-vulkan-capable- > libreoffice-user-interface-using-the-skia-library/ It could be interesting to have these info in LO website. After all, Skia is not exclusive to collaboraoffice.