Line Segments Disappearing

Aug 26, 2010 at 6:22 AM
Edited Aug 26, 2010 at 6:44 AM

Here is a quick screen capture of zooming in with DeepEarth (SL4 Branch) on a path that contains about 800 points:

http://www.youtube.com/watch?v=Poh5VuM9Vcg

As you can see parts of the path start to disappear. This is using a geometry layer with TransformUpdate. I need that mode because I will be showing paths with possibly thousands of points.

Any ideas on how I might be able to fix this?

Note that with PanOnlyUpdate the path isn't shown at all, and with ElementUpdate it displays fine, but of course performance is worse.

Also note that I tried it with 20,000 points and even though the lines still disappear when zooming in the performance of DeepEarth with this number of points is impressive.

thanks, Andy

Sep 4, 2010 at 6:33 AM

I had an epiphany and solved it.  When zooming in the lines are scaled, including the stroke thickness. The ScaleAdjustment is allowed to drop too low and the lines become too thin.

Andy

Sep 4, 2010 at 1:47 PM
ajayre wrote:

I had an epiphany and solved it.  When zooming in the lines are scaled, including the stroke thickness. The ScaleAdjustment is allowed to drop too low and the lines become too thin.

Andy

Do you have a patch ?

Sep 4, 2010 at 5:56 PM

No, although it solves the disappearing line problems that nobody else sees, the way the lines look at full zoom is still a bit odd. I want to fix that first.

Andy

Sep 4, 2010 at 6:02 PM
ajayre wrote:

No, although it solves the disappearing line problems that nobody else sees

Andy

I see see the problem and because of it, i have hacked around the poor performance with many points
but the solution i have is not good enough, and therefore i am looking forward to your solution

Sep 6, 2010 at 3:50 AM
LiFo wrote:
ajayre wrote:

No, although it solves the disappearing line problems that nobody else sees

Andy

I see see the problem and because of it, i have hacked around the poor performance with many points
but the solution i have is not good enough, and therefore i am looking forward to your solution

See the patch I just uploaded.

CoordHelper.LogicalToPixel is the bottleneck when using paths with thousands of points and ElementUpdate mode. This function has several flaws:

  • Create three point objects on the heap for every point in the path (all but one are discarded of course after creation)
  • Uses 64-bit division
  • Uses Math.Log and Math.Pow

My patch splits the LogicalToPixel function into two parts. It performs as much of the calculations as possible in the first part and the second part contains only the point-specific transformation. The first part is executed only once for each path transformation instead of for each point. I've also eliminated the Math.Log and Math.Pow functions.

With my 7,000 point test path there is a very noticeable speed increase. Now I don't have to suffer the TransformUpdate mode.

Andy

Apr 18, 2011 at 9:53 AM

Hi,

I have the same performance problem with SL4 branch. When displaying some points (only 250 in my case...), there is a huge performance issue. Changing the UpdateMode doesn't change anything. Could anyone provide me some piece of code that is able to display more than 5K points ? This would be very helpful...

I have also the same problem of "line disappearing".

Thanks

Apr 18, 2011 at 10:32 AM

I ended up ditching DeepEarth and writing my own control without all these issues but with an order of magnitude better performance. Only took me a few evenings (which is less than the time I spent fighting with DeepEarth).

Apr 18, 2011 at 10:42 AM

Hi ajayre,

What do you mean by "I ended up ditching DeepEarth and writing my own control" ? Did you rewrite a whole DeepEarth-like project, or only a control for DeepEarth that is able to manage more than a few hundreds of points ? Thank you.

Apr 18, 2011 at 10:56 AM
Edited Apr 18, 2011 at 11:01 AM

DeepEarth is huge and I don't need 95% of the features. I wrote a control that only has the features I need and therefore is also a faster download for my users. My control isn't "for" DeepEarth but is instead of. I wrote it from scratch and it contains less than 16 classes.

This code is at the core of the OpenStreetMap layer: http://msdn.microsoft.com/en-us/library/bb259689.aspx

Apr 18, 2011 at 12:41 PM

Looks like you made a good choice, but unfortunately we chose DeepEarth for our project because we had no time to write a control from scratch.

But apparently you were able to use DeepEarth with a high number of points (20,000) before writing your own control. Could you please give me some leads to get the same result ? This would be very helpful.

Apr 18, 2011 at 1:20 PM
Edited Apr 18, 2011 at 1:23 PM

I posted a patch to the DeepEarth patch system and referenced it in a post above.

The other issue I had with DeepEarth is that although the smooth zooming is cool, I found it kept stopping in-between the pre-defined zoom levels for OpenStreetMap, resulting in a "fuzzy" blend of two images. I opted with my control to stick with the pre-defined zoom levels to get maps that are always crisp and readable. Good luck.

Apr 19, 2011 at 1:12 PM

Hi Ajayre,

I'm also encountering the same issues that you mentioned with DeepEarth. I was wondering if you could please share your source code for the simplifed control?

Regards, Rob 

Apr 19, 2011 at 2:04 PM
Edited Apr 19, 2011 at 2:05 PM

.