Created attachment 120268 [details] spreadsheets file with charts Version: 5.1.0.0.alpha1+ (x64) Build ID: b051510796dcf289edcd03737087176e53bbe4b8 TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-10-29_12:39:33 Locale: ru-RU (ru_RU) OS: Windows 7 HB x86-64 with the active option "Use OpenGL for all rendering", zoom using mouse wheel comes in spurts and with great delay If the option is disabled, the scaling occurs at normal speed and without delay. it just works as it should work
What graphics card / driver version do you have (if possible) ? =) thanks !
(In reply to Michael Meeks from comment #1) > What graphics card / driver version do you have (if possible) ? =) thanks ! graphics card - AMD 7750 driver version - latest from official site AMD, Catalyst 15.7
link on video https://yadi.sk/i/Yn9t5OWFkLqxX
not look this video in browser, download it and see video in player
Created attachment 120726 [details] correct file for reproduce bug sorry, scaling in file from first attach is ok see this file
Running a VCL / GL rendering log on this I see lots of: 870 info:vcl.opengl:17287:1:vcl/source/opengl/OpenGLHelper.cxx:1034: OpenGLTexture 73 868x1021 from data in my local build - seems like we're doing a -ton- of GPU <-> CPU transfers of large bitmaps which takes lots of time (I guess). Need to unwind why that is - presumably it is the cause. I'm suspicious of the rotated text legends but ... ;-) Anyhow - I can reproduce the slowness in rendering here.
Also seems rather unpleasantly slow on a recent -5-1 under windows for me at least with dbgutil enabled ...
It seems that the RenderTextSimpleOrDecoratedPortionPrimitive2D from the drawing layer is de-compising text in vectors of trapezoids (in this case hundreds of them) before rendering them with DrawPolyPolgyon - which is a somewhat curious way of rendering text =) And this for rendering strings like "40000 000 " or somesuch on the rotated legends. Curiously the windows / GL code is taking the same path - as Linux it seems in this case for OGL.
I don't see any rotated text in the two charts (one on each sheet) here? Also, it doesn't seem slow to me. This is in a relatively fresh master build on Windows 10, AMD A10-7800. What am I missing? (Ah, there is another attachment; will try that instead.)
Yeah, the second attachment has rotated text, and zooming is indeed quite slow. Sorry for the noise.
The essential reason why VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D() goes the slow path of getting the decomposition is not just because the text is rotated, but because it is (also) sheared. Updating bug title accordingly.
The shear seems to be something like 0.03. I wonder if that might be the result of some rounding error? Or really intentional?
Anyway, an obvious "fix" for the slowness here would be to change the basegfx::fTools::equalZero(fShearX) test to for instance fabs(fShearX) < 0.05 . But I would really like to investigate more where the text transformation comes from, in what precision it is, and what the corresponding precision of the calculated shear is.
Still, it remains to be investigated why the code is taking this slow path in the case of OpenGL, but not otherwise. Plus, the extreme irony of course is that OpenGL naturally allows all kinds of transformations, certainly including shears, so there isn't really that much need for decomposing text in the OpenGL case. If there just was a way to pass the required transformation as a whole down to the right level of abstraction. Good luck...
Tomaz - I thought that your big line rendering speedups may have helped here; but - apparently not =) rendering text as bazillions of lines is not a great idea (as Tor says) - but perhaps worth a look after Impress (?) =)
Line rendering speedups only helps lines - by avoiding all the decomposition into trapezoids.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=14469e86d30615618401c5984e05f5609edb1e12 tdf#95581: Assume tiny shears are rounding artefacts etc and can be ignored It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3bbdd817042a665d8f02a2bd4ee668840791bc7f&h=libreoffice-5-2 tdf#95581: Assume tiny shears are rounding artefacts etc and can be ignored It will be available in 5.2.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6bac502897585a32c9ad9256c344499d73f7d5ba&h=libreoffice-5-1 tdf#95581: Assume tiny shears are rounding artefacts etc and can be ignored It will be available in 5.1.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Resolving this for now.