Bug 97137 - Slow and different rendering of vector graphics in attached document
Summary: Slow and different rendering of vector graphics in attached document
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.1.6.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.1.2
Keywords: regression
: 98056 (view as bug list)
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2016-01-14 15:11 UTC by Jan-Marek Glogowski
Modified: 2016-10-25 19:07 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
A document containing various vector graphics (884.43 KB, application/odt)
2016-01-14 15:11 UTC, Jan-Marek Glogowski
Details
First page rendered in OOo 3.2.1 (80.48 KB, image/png)
2016-01-14 15:12 UTC, Jan-Marek Glogowski
Details
First page rendered in LO 5.2 master build (159.45 KB, image/png)
2016-01-14 15:13 UTC, Jan-Marek Glogowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Marek Glogowski 2016-01-14 15:11:05 UTC
Created attachment 121935 [details]
A document containing various vector graphics

Scrolling the document is slow, probably because the graph is rendered as circles now instead of dots / a line. I didn't yet inspect it further.
Comment 1 Jan-Marek Glogowski 2016-01-14 15:12:50 UTC
Created attachment 121936 [details]
First page rendered in OOo 3.2.1
Comment 2 Jan-Marek Glogowski 2016-01-14 15:13:25 UTC
Created attachment 121937 [details]
First page rendered in LO 5.2 master build
Comment 3 V Stuart Foote 2016-01-14 16:55:47 UTC
Confirmed, however this is OpenGL dependent. When OpenGL is disabled rendering of graphs become correct, and the scrolling/paging becomes functional.

@Michael another for bug 93529, but seem to have an OK test document.

tested at 5.0.4.2 (2b9802c1994aa0b7dc6079e128979269cf95bc78)
and current master (c71b5b4d2ec76c0a204f9515dece1e0e0689ce3c) correct rendering in both with OpenGL disabled.
Comment 4 V Stuart Foote 2016-01-14 16:57:52 UTC
Jan-Marek,

would you please confirm the version this first goes bad for you, 4.1.6.2 seems early. Thanks.
Comment 5 Jan-Marek Glogowski 2016-01-16 19:18:06 UTC
Very strange. Maybe the result also depends on system libraries.

Now I've tested 
 * LO 5.2 master, 64bit Ubuntu 14.04 trusty chroot
 * LO 4.1.6 + lhm patches,  32bit Ubuntu 12.04 precise chroot
 * LO 4.1.6.2, 64bit Ubuntu 14.04 trusty chroot from releases-bibisect
 * OOo 3.2.1, 64bit Ubuntu 14.04 trusty chroot

I'm running LO instances via remote X ssh. No OpenGL is involved AFAIK.

 * 5.2 master: happens instantly, as attached image
 * 4.1.6 + lhm: doesn't happen instantly. On load the graphs are correct, but if I move them out of view and then scroll them in again, they break.
 * 4.1.6.2: scrolling works correct too, but the 2nd graph on page 3 is always broken.
 * 3.2.1: everything looks correct and additionally it scrolls fast
Comment 6 Tor Lillqvist 2016-01-20 10:34:49 UTC
Note that the pictures might have been SVG initially, but there is no SVG in the .odt file, as far as I see.
Comment 7 Tor Lillqvist 2016-01-20 10:39:58 UTC
Sample backtrace during the slowness:

msvcr120.dll!malloc(unsigned int size) Line 92	C
msvcr120.dll!operator new(unsigned int size) Line 59	C++
basegfxlo.dll!std::_Allocate<std::_List_node<basegfx::trapezoidhelper::TrDeEdgeEntry,void *> >(unsigned int _Count, std::_List_node<basegfx::trapezoidhelper::TrDeEdgeEntry,void *> * __formal) Line 28	C++
basegfxlo.dll!std::allocator<std::_List_node<basegfx::trapezoidhelper::TrDeEdgeEntry,void *> >::allocate(unsigned int _Count) Line 578	C++
basegfxlo.dll!std::_Wrap_alloc<std::allocator<std::_List_node<basegfx::trapezoidhelper::TrDeEdgeEntry,void *> > >::allocate(unsigned int _Count) Line 848	C++
basegfxlo.dll!std::_List_alloc<0,std::_List_base_types<basegfx::trapezoidhelper::TrDeEdgeEntry,std::allocator<basegfx::trapezoidhelper::TrDeEdgeEntry> > >::_Buynode0(std::_List_node<basegfx::trapezoidhelper::TrDeEdgeEntry,void *> * _Next, std::_List_node<basegfx::trapezoidhelper::TrDeEdgeEntry,void *> * _Prev) Line 782	C++
basegfxlo.dll!std::_List_buy<basegfx::trapezoidhelper::TrDeEdgeEntry,std::allocator<basegfx::trapezoidhelper::TrDeEdgeEntry> >::_Buynode<basegfx::trapezoidhelper::TrDeEdgeEntry>(std::_List_node<basegfx::trapezoidhelper::TrDeEdgeEntry,void *> * _Next, std::_List_node<basegfx::trapezoidhelper::TrDeEdgeEntry,void *> * _Prev, basegfx::trapezoidhelper::TrDeEdgeEntry && <_Val_0>) Line 830	C++
basegfxlo.dll!std::list<basegfx::trapezoidhelper::TrDeEdgeEntry,std::allocator<basegfx::trapezoidhelper::TrDeEdgeEntry> >::_Insert<basegfx::trapezoidhelper::TrDeEdgeEntry>(std::_List_unchecked_const_iterator<std::_List_val<std::_List_simple_types<basegfx::trapezoidhelper::TrDeEdgeEntry> >,std::_Iterator_base0> _Where, basegfx::trapezoidhelper::TrDeEdgeEntry && <_Val_0>) Line 1062	C++
basegfxlo.dll!std::list<basegfx::trapezoidhelper::TrDeEdgeEntry,std::allocator<basegfx::trapezoidhelper::TrDeEdgeEntry> >::push_back(basegfx::trapezoidhelper::TrDeEdgeEntry && _Val) Line 1024	C++
basegfxlo.dll!basegfx::trapezoidhelper::TrapezoidSubdivider::TrapezoidSubdivider(const basegfx::B2DPolyPolygon & rSourcePolyPolygon) Line 572	C++
basegfxlo.dll!basegfx::tools::trapezoidSubdivide(std::vector<basegfx::B2DTrapezoid,std::allocator<basegfx::B2DTrapezoid> > & ro_Result, const basegfx::B2DPolyPolygon & rSourcePolyPolygon) Line 953	C++
vcllo.dll!OpenGLSalGraphicsImpl::DrawPolyPolygon(const basegfx::B2DPolyPolygon & rPolyPolygon, bool blockAA) Line 987	C++
vcllo.dll!OpenGLSalGraphicsImpl::drawPolyPolygon(const basegfx::B2DPolyPolygon & rPolyPolygon, double fTransparency) Line 1509	C++
vcllo.dll!WinSalGraphics::drawPolyPolygon(const basegfx::B2DPolyPolygon & rPolyPolygon, double fTransparency) Line 32	C++
vcllo.dll!SalGraphics::DrawPolyPolygon(const basegfx::B2DPolyPolygon & i_rPolyPolygon, double i_fTransparency, const OutputDevice * i_pOutDev) Line 480	C++
vcllo.dll!OutputDevice::drawLine(basegfx::B2DPolyPolygon aLinePolyPolygon, const LineInfo & rInfo) Line 264	C++
vcllo.dll!OutputDevice::drawPolyLine(const tools::Polygon & rPoly, const LineInfo & rLineInfo) Line 254	C++
vcllo.dll!OutputDevice::DrawPolyLine(const basegfx::B2DPolygon & rB2DPolygon, double fLineWidth, basegfx::B2DLineJoin eLineJoin, com::sun::star::drawing::LineCap eLineCap) Line 223	C++
vcllo.dll!OutputDevice::DrawPolyLine(const tools::Polygon & rPoly, const LineInfo & rLineInfo) Line 120	C++
vcllo.dll!MetaPolyLineAction::Execute(OutputDevice * pOut) Line 789	C++
vcllo.dll!GDIMetaFile::Play(OutputDevice * pOut, unsigned int nPos) Line 371	C++
vcllo.dll!GDIMetaFile::Play(OutputDevice * pOut, const Point & rPos, const Size & rSize, unsigned int nPos) Line 586	C++
Comment 8 Tor Lillqvist 2016-01-20 10:42:47 UTC
So clearly the slowness is related to polylines in the VCL metafiles embedded in the document being rendered as polypolygons, using all the required complexities, subdivision into trapezoids etc, to get proper nesting behaviour. One potential way to start unraveling this might be to change the related APIs to pass around some kind of level-of-detail information so that the code doesn't pointlessly spend lots of time on calculating sub-pixel rendering details.
Comment 9 V Stuart Foote 2016-01-20 14:57:49 UTC
(In reply to Tor Lillqvist from comment #6)
> Note that the pictures might have been SVG initially, but there is no SVG in
> the .odt file, as far as I see.

Your right, very sorry I missed that there were no SVGs as claimed in the summary.
Comment 10 Jan-Marek Glogowski 2016-01-22 11:37:25 UTC
Was actually my fault.

I just got the document as a test case and assumed vector == SVG without checking the file. I changed the topic and removed SVG from the keywords. Nevertheless it's the same problem as most SVG graphice, because - in the end - the drawing of the decomposed vector graphics in the drawing layer is  slow.

Should we add a keyword for vector graphics / drawing layer?
Comment 11 Commit Notification 2016-02-25 10:18:51 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d18ad8a7fb3257001a5045e11f3f770a48a7fa69

opengl: shader based polyline rendering - fixes tdf#97137 for OGL

It will be available in 5.2.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 12 Michael Meeks 2016-02-29 09:43:10 UTC
*** Bug 98056 has been marked as a duplicate of this bug. ***
Comment 13 Michael Meeks 2016-02-29 09:43:39 UTC
Marking fixed; thanks Tomaz ! =)
Comment 14 Commit Notification 2016-02-29 09:43:56 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=334288af53e15f4b16f520a48e84e84c6980b8c7&h=libreoffice-5-1

opengl: shader based polyline rendering - fixes tdf#97137 for OGL

It will be available in 5.1.2.

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.