> As i understand, QPixmap stores pixels in the same format as videocard uses, > so drawing QPixmap is a simple copying a chunk of memory from main memory to > videocard's one. For drawing QImage you have to convert pixels to > videoadapter's format first - and this operation takes several times more > time, than copying. So for fast rendering large qimages must not be used at > all in paintEvent() method.
AFAIK QPixmap uses the video card's memory directly. That is why it is not threadsafe. I solved the problem with the black screen on DEM overlays. The patch is in SVN. And I played a bit with the pixmap version. One thing that caught my attention is the slow polyline redraw for Garmin maps. When moving the map only the polygons are drawn. The moving is smoother for the pixmap version. As expected. But when the map move is stopped it takes longer to draw all the lines. I can't really explain why. Maybe because I use a map with a lot of lines defined as bitmaps. And these lines are handled as QImage because it's necessary to access the pixel matrix directly. As each of these QImage objects have to be drawn in a QPixmap buffer it might take longer than to draw them on a QImage buffer and to draw that buffer to the video card only once. Maybe. It's just a guess. @Albrecht & Michael can one of you both test this on OS X. I would be interested if the little obnoxious transparent problem on some OS X based platforms can be solved by that. Right now I am still not decided what to do. Using QPixmap has some advantages but it introduces new bugs and problems that have to solved, too. I would like to see more on the pro side to make such a deep change on the code. As the change affects many aspects of QLGT I would like to have this tested very carefully. It's better to find and solve the bugs now. If that makes it into the trunk the bugs will hit you anyway on the following release :) Oliver > > I've written a simple test program - > http://guryanov.org/stuff/testimage.tar.gz. Run it with path to large image > file as argument and it will draw image in a loop, method of draw can be > changed by pressing any key on the keyboard. Check draw time and CPU load - > it much smaller when drawing with pixmaps. > > >> I like to ask everyone who compiles QLGT on his own to compare both >> versions and to give feedback. >> >> >> Oliver >> >> >> >>> Hi Dmitry, >>> >>> I applied your patch and recorded frame rates quite the same as yours. >> Surely it's not as fast as a browser application that simply moves a static >> picture. Keep in mind that QLGT immediately starts to update the screen >> while moving the map. Most applications wait until you finish the move and >> update the map later. Thus with every screen update the map is rendered from >> scratch. >> > > >>> >>> But anyway, I am nosy how QLGT would perform if I do not use QImage at >> all. Maybe it's worth dropping the thread safeness and use a special thread >> save draw() for the cases it's needed. As I am a bit busy the next days this >> might take a bit. >>> >>> >>> Oliver >>> >> >> > ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
