[Marble-devel] Re: Review Request: introduce optimized code path for Mercator projection

[Torsten Rahn]

> On 2010-12-13 20:21:29, Torsten Rahn wrote:
> > /trunk/KDE/kdeedu/marble/src/lib/FastMercatorTextureMapper.cpp, line 85
> > <http://svn.reviewboard.kde.org/r/6109/diff/1/?file=42509#file42509line85>
> >
> >     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.
> >
> 
> Bernhard Beschow wrote:
>     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.
> 
> Bernhard Beschow wrote:
>     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.

> 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). 


- Torsten


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


On 2010-12-22 22:33:36, Bernhard Beschow wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6109/
> -----------------------------------------------------------
> 
> (Updated 2010-12-22 22:33:36)
> 
> 
> Review request for marble.
> 
> 
> Summary
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdeedu/marble/src/lib/AbstractScanlineTextureMapper.h 1208706 
>   /trunk/KDE/kdeedu/marble/src/lib/AbstractScanlineTextureMapper.cpp 1208706 
>   /trunk/KDE/kdeedu/marble/src/lib/CMakeLists.txt 1208706 
>   /trunk/KDE/kdeedu/marble/src/lib/TextureLayer.cpp 1208706 
>   /trunk/KDE/kdeedu/marble/src/lib/TileScalingTextureMapper.h PRE-CREATION 
>   /trunk/KDE/kdeedu/marble/src/lib/TileScalingTextureMapper.cpp PRE-CREATION 
> 
> Diff: http://svn.reviewboard.kde.org/r/6109/diff
> 
> 
> Testing
> -------
> 
> 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.
> 
> 
> Thanks,
> 
> Bernhard
> 
>

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