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 Sun, 25 Aug 2013 16:35:29 GMT
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
>>
>> 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
>
>


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


Mime
View raw message