Hi,
I forgot to mention, that I have used a debug-build. On a pro build the
results are better. Only my file with 60000 data points in a point only
XY-chart crashes there.
Kind regards
Regina
Regina Henschel schrieb:
Hi Clarence,
I have now finished some tests. Using nstep=10 drops too many data
points if the total number of points is only slightly above 20000. The
result is ugly. It works better with my approach, please try it.
I then tried to find an upper bound for a threshold. There I find, that
more than 31000 data points cause a crash with "bad allocation" error.
It works till 30000 data points. So there needs to be done something
anyway. We have over 1 million rows and user will try to use them.
But near to the not crashing 30000 data points, AOO becomes easily not
responding for several seconds. It is enough to click on the chart, or
to hover something that will show a tooltip, to bring AOO in this state.
AOO comes back after a few seconds, but normal working is not possible.
Therefore for normal working a lower threshold is needed and higher
values only on request of the user. I like the idea to have a user
interface to set such threshold. But that cannot be done for AOO4.0.1.
My suggestion is, to use for AOO4.0.1 a threshold of max. 16000. With my
approach, you get then at least 8000 data points, but not more than
16000. Latter is already very slow.
I think, that for AOO4.0.1 it is enough to only solve it for AreaChart.
Such large amount of data points likely comes from measuring. Such data
will be presented with those chart types covered by AreaChart. But that
is only my personal opinion.
And for AOO4.1 the "bad allocation" problem has to be solved directly or
all possible data series have to be limited. The problem is not the
manual creation of a spreadsheet and use as data provider, but
generating charts from a database or from measurement values, including
automatic generation by scripting.
Kind regards
Regina
Regina Henschel schrieb:
Hi Clarence,
my basis build has just finished and I need a little bit time to apply
your patch and test it. But a suggestion beforehand: You use
sal_Int32 nStep = nEndIndex >= 20000 ? 10 : 1;
which produces a fix percent of dropped data points, e.g. from 24000
only 2400 would be kept. Wouldn't it be better, to make this dependent
on the amount of data points?
Something like
sal_Int32 nStep = nEndIndex / 20000 +1;
?
Kind regards
Regina
bugzi...@apache.org schrieb:
Clarence GUO <clarence.guo...@gmail.com> has asked for review:
Bug 122822: Correct viewing of XY-, Column- and Line-Charts limited to
10000
records + 1 Heading row
https://issues.apache.org/ooo/show_bug.cgi?id=122822
Attachment 81367: Fix patch
https://issues.apache.org/ooo/attachment.cgi?id=81367&action=edit
------- Additional Comments from Clarence GUO
<clarence.guo...@gmail.com>
The earlier fix patch has a problem. It cannot fix the problem of
hover tip
which is mentioned by Regina Henschel.
It will always get drawing shape's name for hover tip. But drawing
shape's name
comes from the index when rendering these shapes. So if pick data
points before
rendering, the index will be always from 1 to the number it picked out.
In order to solve this problem, picking must at view side, say
rendering.
As each chart type has it's own rendering, my fix is only in
AreaChart.cxx.
Area, line, XY and Radar chart share one implementation in this file.
I tested
sample file of 121058, it's a line chart, convert it to area, XY,
radar charts,
there are all performance problem. So my fix is only for these chart
types. If
there are performance problem for other chart types who have huge
data, then it
should be fixed separatedly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
