Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <521385E0.7060400@t-online.de>
Date: Tue, 20 Aug 2013 17:06:08 +0200
From: Regina Henschel <rb.henschel@t-online.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20
MIME-Version: 1.0
To: dev@openoffice.apache.org
Subject: Re: review requested: [Bug 122822] Correct viewing of XY-, Column-
 and Line-Charts limited to 10000 records + 1 Heading row : [Attachment 81359]
 Fix patch
References: <bug-122822-0@https.issues.apache.org/ooo/>
	<bug-122822-0-lCzsAU3Dml@https.issues.apache.org/ooo/>
	<52136016.5050601@t-online.de>
 <CAHDqS0mXW7zs_O4iAL6-wc5JgZdY9oa=worYwfyMuEdAwi6HZw@mail.gmail.com>
In-Reply-To: 
 <CAHDqS0mXW7zs_O4iAL6-wc5JgZdY9oa=worYwfyMuEdAwi6HZw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Clarence,

Clarence GUO schrieb:
> Hi~ Regina,
> Do you mean the change should at view side?

Yes.

  But each chart type has it's
> own implementation of view.

And each chart has its own performance problems. Drawing an XY-chart 
with only points might work, but showing data point labels will fail. 
Drawing a line in 2D might be fine, but drawing the same line in 3D will 
fail. Drawing only points might work, but drawing a regression line or 
smoothed curve in addition might fail.

  So if we want to change at view side, we have
> to change code in each implementation. That code looks not very effective.
> My change doesn't change model because the data source range can be kept.

But is solves only Calc as data provider.

Changing the view would also not change data source range but only the 
amount of generated shapes.

Another problem is, that there must be something additional in Excel 
import, because using ods works with the same amount of data. Delete the 
chart in Excel, open the file in AOO and then make a new chart. It is 
slow, but works.

Solving it inside chart has the opportunity to bring the threshold to 
UI, as suggested in comment 23.

> It only picked some points from model to prepare viewing for drawing
> performance consideration.

But I'm not an expert here and you should wait, what our experienced 
developers think.

A nitpick: the step should not be fix but depend on the amount of data 
relative to a threshold.

Kind regards
Regina


> 2013/8/20 Regina Henschel <rb.henschel@t-online.de>
>
>> Hi,
>>
>> I think, that it is the wrong place for a correction. A chart is a
>> document and the chart itself should take care, that it draws its data
>> series in a reasonable time.
>>
>> 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<https://issues.apache.org/ooo/show_bug.cgi?id=122822>
>>>
>>> Attachment 81359: Fix patch
>>> https://issues.apache.org/ooo/**attachment.cgi?id=81359&**action=edit<https://issues.apache.org/ooo/attachment.cgi?id=81359&action=edit>
>>>
>>>
>>> ------- Additional Comments from Clarence GUO <clarence.guo.bj@gmail.com>
>>> The root cause of this defect is in fix of 121058, only some points were
>>> picked
>>> up in order to save loading time and memory for tens of thousands of data
>>> points. All data points were divided into many small groups and only
>>> picked min
>>> and max points from one group. The reason why only picked min and max
>>> points
>>> instead of using a regular distance is, for example, if there is a column
>>> or a
>>> line chart, most of data points are around max value 100 and min value
>>> 10, only
>>> if we pick max and min values from one group, the chart can keep it's
>>> original
>>> outline. But if we use a regular distance, we might only get some
>>> mid-value(for
>>> example 50) of the chart and will miss the chart outline.
>>> But the mechanism never consider scatter chart or bubble chart which have
>>> multiple data sequence in one series. For example, for scatter chart, one
>>> series has two sequence, x values and y values. A x value and a y value
>>> must be
>>> a pair. Then when pick x values, a min and a max values were picked. When
>>> pick
>>> y values, another min and max values were picked. However, the picked min
>>> and
>>> max x values probably are not in one pair of min and max y values. For
>>> example,
>>> index of min and max x values are 10 and 40. It should get No. 10 and No.
>>> 40
>>> values from y values, but it might get No. 30 and No. 35. So in this
>>> case, the
>>> chart data are totally corrupt. That is the root cause.
>>> My fix will roll back code of 121058 in ScChart2DataSequence::**
>>> getNumericalData
>>> and add new fix code in ScChart2DataSequence::**BuildDataCache(), then
>>> wrong axes
>>> data label issue mentioned by Regina Henschel can be fixed. And new code
>>> will
>>> use regular distance to pick up points then problem for scatter chart and
>>> other
>>> charts which have multiple sequences in one series can be fixed. If the
>>> distance is small enough, fore-mentioned chart outline issue is no
>>> problem. So
>>> I use 5 as regular distance.


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