This is related to https://bugs.freedesktop.org/show_bug.cgi?id=36779 . It is basically about rendering of charts involving large numbers of data points being slow, but with a testable condition. Steps to reproduce slow chart rendering: 1. Download this file: https://openmalaria.googlecode.com/git-history/1e60bce9bd62a87c6e80fc81b96915089614eda1/test/expected/ctsoutSimpleMPDTest.txt 2. Load into LibreOffice: `LibreOffice --calc ctsoutSimpleMPDTest.txt` 3. Select start from line 2, and select tab (\t) as a field separator 4. Select columns A and C 5. Click the "insert chart" button 6. Select XY (Scatter) 7. Select "Lines only" (third image) 8. Wait until the UI is responsive again (for me this takes several seconds) (Note: the lag occurs even before clicking "finish" on the plot wizard.) Expected behaviour: no major lag. UI is never unresponsive for more than around half a second _and_ the chart is rendered in under a second (even if at reduced quality).
*** Bug 85882 has been marked as a duplicate of this bug. ***
This bug is certainly a duplicate of an existing one, but I could not find that yet. If it stays open, a reduced version of the test data should be directly attached. This test chart only contains 7448 x/y samples. On my machine (Intel Core i7-2600K @ 3.4 GHz) I notice about 2 seconds of delay when switching from "Points only" to "Lines only" (in LibreOffice 4.2.6.2 on Windows 7). I often work with data sets containing ~32k samples, where the corresponding delays are really annoying. PS: If you read this and just want to express that you are also affected, please don't post a comment!. Just CC yourselves instead, to keep the issue readable.
Here's my understanding of the problem. Line graph are drawn using the PolygonStrokePrimitive2D primitive (see sdrdecompositiontools.cxx) When the UI is frozen, the stacktrace is: (gdb) bt 10 #0 solveHorizontalEdges (rTrDeSimpleEdges=std::vector of length 3567, capacity 4096 = {...}, this=0x7fffffffb3c0) at basegfx/source/polygon/b2dtrapez oid.cxx:475 #1 TrapezoidSubdivider (rSourcePolyPolygon=..., this=0x7fffffffb3c0) at basegfx/source/polygon/b2dtrapezoid.cxx:591 #2 basegfx::tools::trapezoidSubdivide (ro_Result=std::vector of length 0, capacity 0, rSourcePolyPolygon=...) at basegfx/source/polygon/b2dtrapezoid. cxx:956 #3 0x00007fffe0a663ff in X11SalGraphicsImpl::drawPolyPolygon (this=0x1bd26d0, rOrigPolyPoly=..., fTransparency=0) at vcl/unx/generic/gdi/gdiimpl.cxx: 1554 #4 0x00007ffff2493769 in SalGraphics::DrawPolyPolygon (this=0x1bd4c50, i_rPolyPolygon=..., i_fTransparency=i_fTransparency@entry=0, i_pOutDev=i_pOutDev@entry=0x1bd89a8) at /home/pierre -eric/code/libreoffice/vcl/source/gdi/salgdilayout.cxx:457 #5 0x00007ffff237de27 in OutputDevice::drawLine (this=this@entry=0x1bd89a8, aLinePolyPolygon=..., rInfo=...) at vcl/source/outdev/line.cxx:260 #6 0x00007ffff237f4a5 in OutputDevice::drawPolyLine (this=this@entry=0x1bd89a8, rPoly=..., rLineInfo=...) at vcl/source/outdev/polyline.cxx:247 #7 0x00007ffff237eee6 in OutputDevice::DrawPolyLine (this=0x1bd89a8, rB2DPolygon=..., fLineWidth=fLineWidth@entry=5.2791686397418474, eLineJoin=eLineJoin@entry=basegfx::B2DLINEJOIN_ROU ND, eLineCap=eLineCap@entry=com::sun::star::drawing::LineCap_BUTT) at vcl/source/outdev/polyline.cxx:215 #8 0x00007fffee7f1fee in drawinglayer::processor2d::VclProcessor2D::RenderPolygonStrokePrimitive2D (this=this@entry=0x1c2f0b0, rPolygonStrokeCandidate=...) at breoffice/drawinglayer/source/processor2d/vclprocessor2d.cxx:1322 #9 0x00007fffee7ed695 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D (this=0x1c2f0b0, rCandidate=...) at drawinglayer/sour ce/processor2d/vclpixelprocessor2d.cxx:1074 The polypolygon to trapezoid method is complex and doesn't scale well when 10.000+ edges are involved. I tested various patches but I'm not sure which one is better
Created attachment 113430 [details] 1st version First approach: do not use the generic 'draw lines as polypolygon' code path, but use the simpler 'draw lines as hair line'. Pros: render times are acceptable Cons: ignore line width, so graph looks different (line graphs have a default line width of 80)
Created attachment 113431 [details] Screenshot with draw_as_hair_line.patch applied
Created attachment 113432 [details] 2nd version This patch changes the way line drawing is done. Instead of using the drawPolyPolygon method, each polygon is drawn separatly. Pro: render time is acceptable Con: ?
Created attachment 113433 [details] Screenshot with draw_as_hair_polygon.patch applied
Other potential approaches: * improve TrapezoidSubdivider performance on large set (b2dtrapezoid), maybe using spatial partitioning. * add a proper DrawLine primitive
The results look great Pierre! Using thinner lines when there are many points is actually an advantage (at least in this example), though maybe ignoring the line width is a bit cheeky.
Hi Guys, ignoring the LineWidth is a no-go from my POV. It changes the intended visualization. Maybe change the default LineWidth to 0 in the model description and thus use hairline in the future, but that would then work for all newly created or adapted/changed charts. Just drawing hairlines instead of lines with the given width is a wrong visualization (discretization) of given geometry data, but helps to detect and show the weak point. The better way which you already intend is to find a better way to render PolyPolygons with a LineWidth != zero. This is what is done on Win and Mac already. Problem on Linux is that X does not have a direct command to draw fat lines with evtl. pattern and the correct line start/end and cap styles. Due to that the line geometry is prepared as filled PolyPolygons (using primitives and basegfx, but may also be old stuff in vcl). If this is currently converted to trapezoids we should check if this is needed - at least, X can draw filled polygons (but not PolyPolygons). With the recent moves to more advanced system renderers on Linux it will be solvable much better. Ideally a system-dependent, optimized primitive renderer chooses what to do for the given render platform (X or OpenGL or ...). Evtl it is possible to avoid trapezoidation, that would help, not sure if optimizing it will do much in the sense of runtime complexity...
*** Bug 96340 has been marked as a duplicate of this bug. ***
*** Bug 105912 has been marked as a duplicate of this bug. ***
I'm getting the same issue on Ubuntu 16.04 using Calc version 5.1.6~rc2-0ubuntu1~xenial2. Calc is completely unresponsive and when it does eventually draw a chart it's a rendering mess. My data set has about 20 thousand points (temperature data from a logger).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 147076 [details] The test data I have now downloaded the originally used test data from https://raw.githubusercontent.com/SwissTPH/openmalaria/1e60bce9bd62a87c6e80fc81b96915089614eda1/test/expected/ctsoutSimpleMPDTest.txt and attached it here.
Testing LO 6.1.2.1 (x64), I can still confirm the ~2 sec delay from my comment 2 (on the same OS and HW).
Dear Diggory Hardy, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I still see the ~2 sec delay, now on Intel Core i7-4770 @ 3.40GHz. Version: 6.3.3.2 Build ID: 1:6.3.3-0ubuntu0.18.04.1~lo1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_DK.utf8); UI-Language: en-US Calc: threaded
Created attachment 176134 [details] Example file with data Here is the data copied into a document. I guess I get the slight lag when selecting the chart type, but is it normal to not see any lines in the chart? I don't see them on Windows or Linux. Tested also with 7.2, 6.4 and 6.3 Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 5c5f36aa73b11356a3bff0a9cc8b5fe8d1a776b9 CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded
Created attachment 177152 [details] ods file with text converted to data (numbers) (In reply to Buovjaga from comment #19) > Created attachment 176134 [details] > > I guess I get the slight lag when selecting the chart type, but is it normal > to not see any lines in the chart? I usually import csv without this particular problem. The text data records need each column to be converted to data. Clicking on a cell in column C, the value is preceded by a ' and left-justified. We don't see the ' in the cell, but can see it in the formula bar display '1.2345. Click select a column, such as C, then Data>Text to Columns then OK. All the digits in cells go right-justified and lose their ' disguise - become numbers. For some reason I needed to do each column one at a time; the conversion menu is grey for selection of several columns. Attached the converted xyscatter as xyscatter2 (ods). Then lines or points or choice are seen.
On my (addmittedly fast) machine, running the stuff mentioned here never results in a lag of more than 1 second.
On current master, that is, which has seen lots of optimisations recently
Dear Diggory Hardy, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug