Bug Hunting Session
Bug 95581 - OGL: Sheared (by accident?) text in charts slow
Summary: OGL: Sheared (by accident?) text in charts slow
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha1
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.3.0 target:5.2.0.1 target:5.1.5
Keywords:
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2015-11-04 18:27 UTC by Roman Kuznetsov
Modified: 2016-10-25 18:55 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
spreadsheets file with charts (20.57 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-11-04 18:27 UTC, Roman Kuznetsov
Details
correct file for reproduce bug (25.15 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-11-22 21:14 UTC, Roman Kuznetsov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2015-11-04 18:27:37 UTC
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
Comment 1 Michael Meeks 2015-11-04 20:03:05 UTC
What graphics card / driver version do you have (if possible) ? =) thanks !
Comment 2 Roman Kuznetsov 2015-11-04 20:32:42 UTC
(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
Comment 3 Roman Kuznetsov 2015-11-09 20:08:14 UTC
link on video https://yadi.sk/i/Yn9t5OWFkLqxX
Comment 4 Roman Kuznetsov 2015-11-09 20:11:39 UTC
not look this video in browser, download it and see video in player
Comment 5 Roman Kuznetsov 2015-11-22 21:14:15 UTC
Created attachment 120726 [details]
correct file for reproduce bug

sorry, scaling in file from first attach is ok

see this file
Comment 6 Michael Meeks 2015-12-16 11:26:05 UTC
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.
Comment 7 Michael Meeks 2016-01-12 22:10:13 UTC
Also seems rather unpleasantly slow on a recent -5-1 under windows for me at least with dbgutil enabled ...
Comment 8 Michael Meeks 2016-01-12 23:27:26 UTC
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.
Comment 9 Tor Lillqvist 2016-01-25 14:25:21 UTC Comment hidden (obsolete)
Comment 10 Tor Lillqvist 2016-01-25 14:26:55 UTC Comment hidden (obsolete)
Comment 11 Tor Lillqvist 2016-01-25 15:13:41 UTC
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.
Comment 12 Tor Lillqvist 2016-01-25 15:46:52 UTC
The shear seems to be something like 0.03. I wonder if that might be the result of some rounding error? Or really intentional?
Comment 13 Tor Lillqvist 2016-01-25 15:59:45 UTC
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.
Comment 14 Tor Lillqvist 2016-01-25 18:34:02 UTC
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...
Comment 15 Michael Meeks 2016-03-02 17:32:58 UTC
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 (?) =)
Comment 16 Tomaz Vajngerl 2016-03-02 18:34:49 UTC
Line rendering speedups only helps lines - by avoiding all the decomposition into trapezoids.
Comment 17 Commit Notification 2016-06-01 10:38:06 UTC
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.
Comment 18 Commit Notification 2016-06-01 11:03:22 UTC
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.
Comment 19 Commit Notification 2016-06-06 08:32:09 UTC
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.
Comment 20 Tor Lillqvist 2016-06-08 09:43:58 UTC
Resolving this for now.