<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 />



 <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;">Works fine on my Desktop and on the N900, even fixes a crash there. Given that the patch changes no strings and is not a new feature, it should be no problem to commit it to trunk.

I wonder whether we should listen to quality settings in some way, e.g. introducing

    bool const highQuality = viewParams-&gt;mapQuality() == HighQuality || viewParams-&gt;mapQuality() == PrintQuality;
    painter.setRenderHint( QPainter::SmoothPixmapTransform, highQuality );

after the QPainter creation. That&#39;d possibly reduce much of the speed gain though.
</pre>
 <br />







<p>- Dennis</p>


<br />
<p>On December 12th, 2010, 11:11 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-12 23:11:04</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&#39;t hit.</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">(1205882)</span></li>

 <li>/trunk/KDE/kdeedu/marble/src/lib/AbstractScanlineTextureMapper.cpp <span style="color: grey">(1205882)</span></li>

 <li>/trunk/KDE/kdeedu/marble/src/lib/CMakeLists.txt <span style="color: grey">(1205882)</span></li>

 <li>/trunk/KDE/kdeedu/marble/src/lib/FastMercatorTextureMapper.h <span style="color: grey">(PRE-CREATION)</span></li>

 <li>/trunk/KDE/kdeedu/marble/src/lib/FastMercatorTextureMapper.cpp <span style="color: grey">(PRE-CREATION)</span></li>

 <li>/trunk/KDE/kdeedu/marble/src/lib/TextureLayer.cpp <span style="color: grey">(1205882)</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>