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.
Created attachment 121936 [details] First page rendered in OOo 3.2.1
Created attachment 121937 [details] First page rendered in LO 5.2 master build
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.
Jan-Marek, would you please confirm the version this first goes bad for you, 4.1.6.2 seems early. Thanks.
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
Note that the pictures might have been SVG initially, but there is no SVG in the .odt file, as far as I see.
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++
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.
(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.
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?
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.
*** Bug 98056 has been marked as a duplicate of this bug. ***
Marking fixed; thanks Tomaz ! =)
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.