Am 01.11.2011 21:22, schrieb Michael Klein: > Hi, > >>> Am 29.10.11 14:01 schrieb(en) Oliver Eichler: >>>> @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. >>> >>> Tested it on 10.5/Intel, and unfortunately it does /not/ fix the >>> rendering issue. Didn't test it on 10.4/PPC yet (as building takes >> >> :( well it was worth a try. Thanks. > > can you elaborate on that rendering issue?
Well, if polylines cross white background they are surrounded by staircase shaped artifacts. It looks like some smoothing filter has an overflow. So far there is no real solution how to fix it and the bug only occurs on a certain OS X/hardware setup. > >> I tried to speed up Garmin maps a bit. The results are in SVN. >> Unfortunately exchanging QImage with QPixmap for line drawing did not >> help. Still vector maps are rendered slow. > > I recently played with another way to speed up polylines in Garmin maps: > Instead of trying to make the actual drawing faster I tried to reduce > the number of images to be drawn with the Douglas-Peucker algorithm. > It's not uncommon to have >>10.000 QImages in the viewport, many (if not > most) of them can often be eliminated without sacrificing significant > map detail. In some cases the time spent in drawPolylines() is halved. > > Patch (against trunk) is attached. The functionality can be switched on > and off the config dialog. Currently it's also possible to directly > enter the epsilon value there. Woah! What a patch! That stuff is cool. I challenged it with various maps today. It's really impressive. Especially on the outer zoom scales the major street polylines where a performance hit. Now they render quite as fast as the polylines on the closer zoom levels. Additionally it flattens the ugly staircase polylines that seem to be en vogue on outer zoom scales these days. The only caveat I recognized where some edgy polylines of large curves like highway ramps. That stuff has to make it into svn. I would just like to ask you for a few changes: * Skip making it an option. The benefits are good enough to have it permanently on. And I doubt that 99% of the users know what it does, how it works and why to use this option anyway. * But switch it off for closer zoom levels. Map contributor will get a heart attack if they do not see their polyline as defined. On closer views the speed up is not noticeable anyway. * Get rid of that class in a method. :) That is ugly. And it only defines a single method anyway. * There is a 2nd draw method for lines. That has to do the optimization, too. It draws the foreground of a two color road. Good work! Oliver ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
