openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regina Henschel <rb.hensc...@t-online.de>
Subject Re: review requested: [Bug 122822] Correct viewing of XY-, Column- and Line-Charts limited to 10000 records + 1 Heading row : [Attachment 81367] Fix patch
Date Fri, 23 Aug 2013 14:37:20 GMT
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
>
> bugzilla@apache.org schrieb:
>> Clarence GUO <clarence.guo.bj@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.bj@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message