[Qgis-user] Re: AW: [Qgis-developer] "Fix problems with incorectly
tutey at o2.pl
Thu Apr 17 12:19:47 EDT 2008
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  (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:
FPWIFP on: 22.441
MLALJ on: 23.585
both off: 27.189
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:
FPWIFP on: 6.257
MLALJ on: 8.661
both off: 14.65
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
Hardware video acceleration and direct rendering work OK on both machines.
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)?
More information about the Qgis-developer