jonessieka / explorercanvas

Automatically exported from code.google.com/p/explorercanvas
Apache License 2.0
0 stars 0 forks source link

Long lines are consistently truncated #50

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Start a new path. Call lineTo a sufficiently large number of times, say
10000 times. Stroke it. Only a fraction of the line segments are drawn
(maybe 20%).

Test case attached (it assumes excanvas.js is placed in the same directory).

Try playing with noLines and noPoints. With noLines = 1 and noPoints =
1000, the complete waveform is drawn in my IE 6. With noLines = 1 and
noPoints = 10000, only the first part of the waveform is drawn. With
noLines = 10 and noPoints = 1000, ten complete waveforms are drawn.

So the problem is not that IE is incapable of drawing so many line
segments, it just can't happen in the same line. Conclusion: excanvas
should chop the lines up when converting it to VML.

I've tested this with the latest excanvas.js on IE 6.

There's a bug report in Flot in case you're interested:
http://code.google.com/p/flot/issues/detail?id=201

Original issue reported on code.google.com by olau%iol...@gtempaccount.com on 21 Oct 2009 at 11:44

Attachments:

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I tried with noPoints = 9567 and everything is drawn, 
but nearly nothing when noPoints = 9568.
It will be totally drawn when noPoints = 9577 ...
VML stops drawing when the path is too long. As you said, a new path should be 
inserted 
when it becomes too long, but it seems to be hard to know what is the real 
limit.

Original comment by fabien.menager on 21 Oct 2009 at 12:25

GoogleCodeExporter commented 9 years ago
Interesting.

I looked into it, and here's a patch against r69. It looks a bit long because 
of the
reindentation, but the gist of it is just the addition of this outer loop:

for (var j = 0; j < this.currentPath_.length; j += chunkSize)

which changes the inner loop to

for (var i = j; i < Math.min(j + chunkSize, this.currentPath_.length); i+\
+) {                                                                            
  if (i % chunkSize == 0 && i > 0) { // move into position for next chunk 
    lineStr.push(' m ', mr(this.currentPath_[i-1].x), ',',
mr(this.currentPath_[i-1].y));                                                  

  }

  ...

The idea is to divide the current path into chunks and construct each of them
separately, inserting an extra point in the beginning of each chunk from the 
end of
the previous one except for the first chunk.

I have set chunk size to 5000 which in the light of your test appears to be a
conservative estimate. Note that this patch does not fix fills so they are still
broken. I'm not sure but I think fixing fills requires using some kind of 
divide and
conquer technique on the shape. I've added some remarks about it.

Original comment by olau%iol...@gtempaccount.com on 21 Oct 2009 at 1:27

Attachments:

GoogleCodeExporter commented 9 years ago
One guess is that the limit here is not actually the number of points, but how 
long
the VML string becomes? You could try repeating the experiment and output how 
long
the string is in each case.

Original comment by olau%iol...@gtempaccount.com on 21 Oct 2009 at 1:31

GoogleCodeExporter commented 9 years ago
For 6567 points I get 113122 characters. For 9568 points I get 113134 
characters. For
9577 I get 113240 characters. So I'd like to retract my string length limit 
theory. :)

I've done some more testing, a chunk size of 9000 seem to work fine too. I can 
draw
100.000 points in one line.

Original comment by olau%iol...@gtempaccount.com on 22 Oct 2009 at 3:06

GoogleCodeExporter commented 9 years ago
Scrap that, 9000 didn't work with a native IE 8. I'm back to a chunk size of 
5000.

I'm going to release a version of excanvas with this patch with Flot very soon.

Original comment by olau%iol...@gtempaccount.com on 23 Oct 2009 at 12:10