Your Idea. Transformations limitation workaround

Topics: General
Nov 3, 2010 at 11:55 AM

Hi Radioman,

On Oct 18/19  you said your idea was working and have made changes to the markers again.

What is/was your idea, and how have the markers changed again.


Nov 3, 2010 at 12:21 PM

...this is related to windows forms version, in the 'old' system when you drag map or move marker, each position of marker was recalculated using current projection, and if conversation code is long and if you have many coordinates to calculate it eats your cpu and lags on user interface, so i've decided to calculate only once per zoom change so markers stays in the same position regardless where you move the map, because it just change offset in translation matrix, so it virtually 'moves'. Nice and efficient. BUT in practice e.Graphics.TranslateTransform function and high offsets makes distortions ;/ Set max zoom and slowly drag, damn effect isn't very pleasant, specially in the satellite mode, so i'm still stuck in the optimization branch ;}

any workarounds? ;/

Dec 11, 2010 at 6:05 AM

The issue I see with performance is when panning (moving the current projection left to right).

I would think that you could do the following to make this fast:

1. Render the markers onto an internal graphics object merged with the tile behind them.

2. Hold that tile in memory and use it as the tile graphic (yes, you would have to render on the fly new markers that come into position, but you'd only do it once)

3. Ignore all updates to the marker geometry (eg boundary, etc) and only draw the map while the mouse is down. Essentially draw the map as if we had no markers at all.

4. When the mouse up occurs, update all marker internal data.

The map would move fast and only update all the expensive floating point operations once (per mouse up)


Dec 11, 2010 at 4:45 PM

...what if marker is in between two tiles, rendering it would involve complex coding... anyway i'm already know transformations limitation workaround using current position point as origin for rendering, so you can pan +- 100k px without any artifacts, and that would change only transformation matrix, so rendering will be done the fastest way without recalculating positions, all i need is just to implement dynamic origin aware system, i'm experimenting on it in optimizations branch, happy way to go ;}

Dec 11, 2010 at 7:31 PM

Interesting. I didn't think about the point being between two tiles. I just assumed that the tile lat/long precsion would be fine enough to prevent that. Since you point it out, it seems that I was wrong to make that assumption.

If I want to play around with it should I get the entire optimization branch or is there a part that is revelant to just this issue?

Dec 11, 2010 at 7:45 PM

if you want to try implement rendering markers directly on tiles use default branch, and if you are interested to help implementing my transformations limitation workaround check the optimization branch, anyway you may need both... ;}