<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/6109/">http://svn.reviewboard.kde.org/r/6109/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On December 13th, 2010, 8:21 p.m., <b>Torsten Rahn</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<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/6109/diff/1/?file=42509#file42509line85" style="color: black; font-weight: bold; text-decoration: underline;">/trunk/KDE/kdeedu/marble/src/lib/FastMercatorTextureMapper.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="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">void FastMercatorTextureMapper::mapTexture( ViewParams *viewParams )</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">85</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span class="n">painter</span><span class="p">.</span><span class="n">drawImage</span><span class="p">(</span> <span class="n">rect</span><span class="p">,</span> <span class="o">*</span><span class="n">tile</span><span class="o">-></span><span class="n">resultTile</span><span class="p">()</span> <span class="p">);</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This is very expensive.
- On one hand it would improve performance dramatically if you'd cache the scaled images.
- On one hand you're using QImage for scaling which is slower than QPixmap.
So ideally you'd create pixmaps from the original QImage tiles and then store the pixmaps in a hash which maps a key that consists of the tile_id + targetsize and you'd map that to the pixmap. This should improve performance dramatically.
</pre>
</blockquote>
<p>On December 13th, 2010, 11:39 p.m., <b>Bernhard Beschow</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I haven't tried using a QPixmap but your suggestion sounds promising.
As for the cache, I figure that each tile would need to be cached up to four times. The reason is that the target tile size probably oscillates by one pixel in each dimenstion when moving the map. Perhaps this could be prevented using QRectF.</pre>
</blockquote>
<p>On December 22nd, 2010, 10:11 p.m., <b>Bernhard Beschow</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Even if I cache all four tile sizes, the speed does not improve at all. In both cases I get 34-36fps.
Moreover, it looks like drawing QPixmaps onto QImages is very slow: I get ~20fps instead of ~36.</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> Even if I cache all four tile sizes, the speed does not improve at all. In both cases I get 34-36fps.
Well, that is to be expected: caching all four tile sizes will largely increase the amount of graphics to be cached (and possibly result in cache misses) so that is something that should get avoided in the first place: instead we need to do the exact subpixel rendering that just requires a single tile.
But more important is the fact that measurements on a desktop computer in this case won't give you any good indications about performance: The desktop is so fast that even software rendering can easily be as fast as taking the images from the cache. In case of usage of QImage the significant bottleneck will be the transfer of the data from the main memory to the graphics card. On the desktop computer resizing and caching can easily be neglectable compared to this transfer so the framerate would always stay the same. There could still be an improvement on the phone since the CPU there is weaker.
> Moreover, it looks like drawing QPixmaps onto QImages is very slow: I get ~20fps instead of ~36.
Yes sure:
When the graphics system used is "native" then your picture stored as a QPixmap is actually stored in the memory of the graphics card. Any simple manipulation like moving and scaling will get handled (quickly) on your graphics card using QPixmaps. In opposite QImages are stored on the computer's RAM. Moving and scaling QImages is CPU intensive and displaying the QImage requires an "upload" to the graphics cards' memory. So this will be slow, too.
Now converting between QPixmaps and QImages forth and back is always slow since the data is transferred between the computers RAM and the graphics card memory forth and back. This is something you always want to avoid! Unfortunately painting a QPixmap on top of a QImage will require that the QPixmap data gets transferred to the RAM in order to be able to draw it on top of the QImage (so you basically get an implicit QPixmap/QImage conversion). So in that case there will be a dramatic performance loss (and that's what you measured). So you only get a speed advantage if you only draw QPixmaps (and don't mix with QImages).
Also you need to be aware of the fact that if you are using graphicssystem "raster" your QPixmaps will internally just be plain QImages. In some use cases and with some graphics drivers "raster" might be faster (it usually is on desktop computers). </pre>
<br />
<p>- Torsten</p>
<br />
<p>On December 22nd, 2010, 10:33 p.m., Bernhard Beschow wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://svn.reviewboard.kde.orgrb/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 Bernhard Beschow.</div>
<p style="color: grey;"><i>Updated 2010-12-22 22:33:36</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;">This patch introduces an optimized code path for the case that both the tile projection and the map projection are of type Mercator. In this very common case, the tiles can be scaled rather than reprojected, promising a significant speedup. Moreover, it seems to avoid crashes in high zoom levels on the N900.</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;">I have measured speedups of up to 2.7 on my system. This seems to depend on the QImage::Format, so format conversion should be avoided in a future version if possible.
The image quality is roughly of outline quality when a discrete zoom level isn't hit.
I get crashes on my Netbook, but not on my other machine. The error message is: "QPaintDevice: Cannot destroy paint device that is being painted". I've got no idea what's going on here. Please help.</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/AbstractScanlineTextureMapper.h <span style="color: grey">(1208706)</span></li>
<li>/trunk/KDE/kdeedu/marble/src/lib/AbstractScanlineTextureMapper.cpp <span style="color: grey">(1208706)</span></li>
<li>/trunk/KDE/kdeedu/marble/src/lib/CMakeLists.txt <span style="color: grey">(1208706)</span></li>
<li>/trunk/KDE/kdeedu/marble/src/lib/TextureLayer.cpp <span style="color: grey">(1208706)</span></li>
<li>/trunk/KDE/kdeedu/marble/src/lib/TileScalingTextureMapper.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdeedu/marble/src/lib/TileScalingTextureMapper.cpp <span style="color: grey">(PRE-CREATION)</span></li>
</ul>
<p><a href="http://svn.reviewboard.kde.org/r/6109/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>