[Qgis-user] Re: AW: [Qgis-developer] "Fix problems with incorectly filled polygons"issues

[Maciej Sieczka]

Martin Dobias pisze:
> <marco.hugentobler at karto.baug.ethz.ch> wrote:

>>  I would say it is like this (afaik at least on X11):
>>
>>  FPWIFP on = QPixmap = rendering on graphics card
>>  MLALJ on = QImage + antialiasing = software rendering
>>  both off = QImage without antialiasing = software rendering

> AFAIK - with FPWIFP on and thus drawing with QPixmap, this means
> rendering using X server (resp. Windows or Mac backend) - so this
> doesn't necesarily means rendering directly on graphics card,
> especially on X server it would depend on extensions that are running
> and the graphics driver.

FWIW here are some of my benchmarking results:

I have one polygon vector layer added [1] (10 MB, a subset of the public 
domain VMAP0 data), redraw the canvas and look at the timing printed in 
terminal debug output. Outside digitizing "FPWIFP on" is always fastest. 
Yet during digitizing it is the slowest (*extremely* slow). The pattern 
can be reproduced with any vector layer AFAICT.


x86 Debian testing, Pentium M 1.86GHz, ATI X700 PCIe + open source
radeon driver, QGIS SVN trunk r8352, QT 4.3.4:

not-digitizing:
FPWIFP on: 22.441
MLALJ on: 23.585
both off: 27.189

digitizing:
FPWIFP on: 433.308 (ouch!)
MLALJ on: 140.221
both off: 38.178


amd64 Ubuntu Gutsy, Core2 E6600 2.40GHz, GeForce 6200 LE PCIe +
proprietary nvidia driver, QGIS SVN trunk r8346, QT 4.3.2:

not-digitizing:
FPWIFP on: 6.257
MLALJ on: 8.661
both off: 14.65

digitizing:
FPWIFP on: 492.04 (ouch!)
MLALJ on: 190.413
both off: 31.917

Interesting - the mode that is fastest in digitizing is the slowest 
outside it. This means you can't have one best-performance QGIS 
rendering mode. When digitizing "both off" is best (and the only 
acceptable, given how much slower the 2 other modes are), while for 
browsing vector data you'll prefer "FPWIFP on" as it gives you 20% - 
100% better performance.

"MLALJ on" is always in the middle - I thought would be most demanding 
in any case, ?

Seems that vertices transparency is a performance killer. Could this be 
improved?

Hardware video acceleration and direct rendering work OK on both machines.

Maciek

P.S.

It seems that the name "Fix problems with incorectly filled polygons" 
does not reflect the option's function anymore. I have never noticed any 
incorectly filled polygon for a very long time, in either rendering 
mode. Those of my data which once ("many months ago") rendered strange 
don't do these days. Maybe that's due to some fix in QT or QGIS itself? 
Does anybody still experience corrupted polygon fill in QGIS? If not, 
maybe it's time to rename the option (don't what to call it though)?

[1]http://www.biol.uni.wroc.pl/sieczka/udostepnione/cropa.tar.bz2