https://bugs.documentfoundation.org/show_bug.cgi?id=151138

            Bug ID: 151138
           Summary: calc chart line width, changes to larger circles
                    overlapping with reversed normals
           Product: LibreOffice
           Version: 5.2.7.2 release
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Chart
          Assignee: [email protected]
          Reporter: [email protected]

Description:
When I set the line width to 0.03 it works correctly for an hour, or for a few
exports to png, but over time the export stops working correctly. It looks
correct on screen, but does not export correctly.
Data series is configured for continuous line, 0.03 inches, 0% transparency.
Leave gap.

Line width at 0.00 has no problems. Larger width seems to trigger the malformed
dots faster. The lines look like they have holes in them, but are actually
reversed normals for the circles, when overlapping and alternating in which
direction their normal points in, looks like holes in the line.

Once the bug starts happening, reopening the document, or even closing and
restarting libreoffice does not clear the problem. It is persistant between
processes. Only rebooting the operating system will solve it. So something
persists in memory that gets corrupted by some kind of memory leak, is what it
looks like.

I've upgraded my OS this month to 64-bit, it is Debian v.9.13, and I am
surprised to find this long-endured bug still there.

I know this is not the Newest version possible, but is newest in the
repository.

After erasing/moving my user profile, the first export was ok. Then I opened a
csv, copy the new lines of data, paste special here in .ods, and export png.
Broken already and rather quickly.

Next I moved out the OO-v3 user so it would really start fresh. The first
export without editing the .ods is bad right away.


Steps to Reproduce:
1.Make a line chart, range is a few thousand lines long.
2.Export to png
3.Wait an hour, repeat #2 until fails.
Honestly I don't know what the trigger is yet, even after years of working
around the bug. What is consistent is the line width, if I want a thicker line,
I have this happen.

I have also edited the line width, export, repeat until it breaks.

Actual Results:
Here's the example to help identify what is going on. my png when broken:
https://www.seahorsecorral.org/images/tests/out-temps-96hr-bad.png

The above is 288 data points per day, so just over 1000 lines.
another example I have shows partially deformed, and partially correct, 6000
data points:
https://www.seahorsecorral.org/images/tests/temps-month_0.03d1.png
It started with 6 series, I edited this line to be 0.03 inches, then slowly
removed the other series until only this one left.


Expected Results:
https://www.seahorsecorral.org/images/tests/out-temps-96hr-good.png

Be consistent over time. and not be a line full of holes.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 5.2.7.2
Build ID: 1:5.2.7-1+deb9u11
CPU Threads: 4; OS Version: Linux 4.9; UI Render: default; VCL: gtk2; 
Locale: en-US (en_US.utf8); Calc: group

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to