<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://svn.reviewboard.kde.org/r/6604/">http://svn.reviewboard.kde.org/r/6604/</a>
</td>
</tr>
</table>
<br />
<p>Ship it!</p>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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?
</pre>
<br />
<div>
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="http://svn.reviewboard.kde.org/r/6604/diff/1/?file=45572#file45572line201" style="color: black; font-weight: bold; text-decoration: underline;">/trunk/KDE/kdeedu/marble/src/lib/PlacemarkLayout.cpp</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">int PlacemarkLayout::maxLabelHeight() const</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">201</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="n">TileId</span> <span class="n">PlacemarkLayout</span><span class="o">::</span><span class="n">placemarkToTileId</span><span class="p">(</span> <span class="n">GeoDataCoordinates</span> <span class="n">coords</span><span class="p">,</span> <span class="kt">int</span> <span class="n">popularity</span> <span class="p">)</span> <span class="k">const</span></pre></td>
</tr>
</tbody>
</table>
<pre style="margin-left: 2em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">const GeoDataCoordinates &</pre>
</div>
<br />
<p>- Torsten</p>
<br />
<p>On March 8th, 2011, 11:49 p.m., Thibaut Gridel wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://svn.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for marble.</div>
<div>By Thibaut Gridel.</div>
<p style="color: grey;"><i>Updated March 8, 2011, 11:49 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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)</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/trunk/KDE/kdeedu/marble/src/lib/PlacemarkLayout.h <span style="color: grey">(1224176)</span></li>
<li>/trunk/KDE/kdeedu/marble/src/lib/PlacemarkLayout.cpp <span style="color: grey">(1224176)</span></li>
</ul>
<p><a href="http://svn.reviewboard.kde.org/r/6604/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>