enthought / tabs

Default Repo description from terraform module
0 stars 0 forks source link

Resample vectors points by zoom level #51

Closed johntyree closed 8 years ago

johntyree commented 9 years ago

This is a second attempt at changing the number of vectors shown by adapting #49 with some of the ideas discussed in it. I based it off of #50 , though, to make sure it will work in that context and to avoid the giant merge conflict that is otherwise inevitable between the two. Make sure #50 goes in first.

It appears to work pretty well, including with the layer selector, but it has some pretty serious garbage collection problems. I haven't dug through it but a quick run through the profiler has it spending literally half it's cpu time in GC.

That said, my hunch is that it's related to the drawing optimizations and could be cleaned up by avoiding calls to things like Array.slice. Even so, it almost runs at full speed, even in the middle zoom levels, which is where the number of visible vectors is greatest.

Closes #7.

kjordahl commented 9 years ago

Yep, I get over half the time in garbage collection as well. Most of the rest is redraw. It's basically unusable for high zooms, but fine for low zooms.

kjordahl commented 9 years ago

So in #49 I get ~3.7 fps at max zoom. In this branch I get <1 fps. I think it's a comparable number of vectors.

johntyree commented 9 years ago

In th worst case, which appears to be zoom level 10 on your branch, I get double or better performance here than in #49 on both my machine and on the mac. It also spends about half of the time in the garbage collector during the first pass which is what I'd expect given the two approaches.

It is exaggerated further after caching kicks in on the second pass through the loop. ~3% GC time after the vectors are cached vs a steady 15% here and full speed (has to delay between frames) vs 4 FPS or worse here.

You're experiencing the opposite?

kjordahl commented 9 years ago

You're experiencing the opposite?

Yes, but it appears to be history dependent. If I zoom in before starting the animation, then it seems to run OK. If I let it run for a cycle zoomed out, then zoom in, it has a lot of trouble.

johntyree commented 9 years ago

Hmmm. I'll play with it some more then

johntyree commented 9 years ago

I can't reproduce that here. You let it run for a full 90 frames zoomed out then try to zoom in and it dies?

johntyree commented 9 years ago

Ok there we go. So it seems to alternate between running very fast and choking to death.

kjordahl commented 8 years ago

Playing with this some more rebased on master, I think this is in fact an improvement. Though there is still a memory leak somewhere, I think it's on master as well. So I'm merging this to move forward.