Summary: | Performance issues with VCL OpenGL backend (linux, mesa-12.0.1, intel) | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Clemens Eisserer <linuxhippy> |
Component: | graphics stack | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | aron.budea, ilmari.lauhakangas, jbfaure, quikee, serval2412, telesto |
Priority: | medium | ||
Version: | 5.2.0.3 rc | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 97937 |
Description
Clemens Eisserer
2016-07-27 21:04:53 UTC
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. |