[Marble-devel] Re: Review Request: PlacemarkLayout: Tile Pyramid mecanism to provide scalable perfo

[Torsten Rahn]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6604/#review10058
-----------------------------------------------------------

Ship it!


Ship it! ... with fixes. 
I tested it and it works extremely well. There are only a few subtle visual differences compared to the previous implementation which we can fix later on.

One thing that still keeps me wondering is the current concept that basically puts a single entry into a single "tile" (and loads the required "upper tile levels" into memory at the same time with all data/tiles being merged in the view). Have you made up your mind how this would work for vector coasts? I guess with polylines we have to do this differently since I guess it's not a viable solution to have the "important" nodes of a polyline stored in lower tile levels and only the more detailed nodes which belong to the higher tile levels "merged in" ... . Any thoughts about this? 



/trunk/KDE/kdeedu/marble/src/lib/PlacemarkLayout.h
<http://svn.reviewboard.kde.org/r/6604/#comment11304>

    include "GeoDataCoordinates.h"



/trunk/KDE/kdeedu/marble/src/lib/PlacemarkLayout.cpp
<http://svn.reviewboard.kde.org/r/6604/#comment11305>

    Can we have some 3-line explanation what this placemarkToTileId does? :-) I figured it but it took me a bit.



/trunk/KDE/kdeedu/marble/src/lib/PlacemarkLayout.cpp
<http://svn.reviewboard.kde.org/r/6604/#comment11303>

    const GeoDataCoordinates &


- Torsten


On March 8, 2011, 11:49 p.m., Thibaut Gridel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6604/
> -----------------------------------------------------------
> 
> (Updated March 8, 2011, 11:49 p.m.)
> 
> 
> Review request for marble.
> 
> 
> Summary
> -------
> 
> I introduce a "TileId" based storage, whereas each placemarks receives a TileId depending on position and popularity.
> More popular placemarks get to high-level "tile level", less popular go to low-level ones.
> For a given BBox, calculating the "Tile pyramid" and getting placemarks from those TileIds provides a small subset of placemarks that should get rendered.
> 
> Some figures: we have currently c.a. 22000 placemarks, and most BBox provides an 10ish TileIds Pyramid, leading so c.a. 400 placemarks.
> The scalability of filtering placemarks sounds quite obvious.
> 
> Tweaking level, placemark popIdx, and radius to level is TODO.
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdeedu/marble/src/lib/PlacemarkLayout.h 1224176 
>   /trunk/KDE/kdeedu/marble/src/lib/PlacemarkLayout.cpp 1224176 
> 
> Diff: http://svn.reviewboard.kde.org/r/6604/diff
> 
> 
> Testing
> -------
> 
> Proof of concept of that Pyramid of TileId storage.
> Please report on the Perfo impression and help tweaking:
> 
> - radius to level table (used to determine at which radius which level should be used),
> - popIdx to level (used to seed placemarks to level according to their PopIdx)
> - filtering the first 300 placemarks to display (should stay untouched)
> 
> 
> Thanks,
> 
> Thibaut
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/marble-devel/attachments/20110415/bff119e4/attachment.htm