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

Martin Dobias wonder.sk at gmail.com
Wed Apr 30 20:05:08 EDT 2008

Hi Maciej,

my reply is quite late, however I hope it can be still useful...

On Thu, Apr 17, 2008 at 6:19 PM, Maciej Sieczka <tutey at o2.pl> wrote:
> [...]
>  digitizing:
>  FPWIFP on: 433.308 (ouch!)
>  MLALJ on: 140.221
>  both off: 38.178
> [...]
>  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.

The only difference between normal mode and digitizing mode is that
for every vertex in editing layer QGIS draws an ellipse with
transparency. Since with FPWIFP the rendered map is stored on X
server, when drawing a semi-transparent ellipse Qt has to ask X server
for the background, apply transparency and again send the modified bit
- one can imagine that this has a lot of overhead instead of just
changing pixels directly.

Such long times for rendering make me think about those vertex markers
- there should be an option to customize them for better performance -
e.g. turn semi-transparency off, change to a simpler shape (cross?) or
turn them completely.

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

Hmm, the fact that with antialiasing on you'll get sometimes faster
results than without antialiasing looks like there are still things
that could be improved in Qt because drawing without AA should be
generally faster (less calculations and memory access).

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

Right, as I've proposed above, allowing some level of customization of
the markers should do it.

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

Yes it's possible that the problem with filling of complex polygons
has gone, but I would still let this option available, although with
some different description (e.g. stating that it's using QPixmap
instead of QImage for rendering and that for usual user it's better to
leave it off, and that transparency and antialiasing is slower with it
turned on)


More information about the Qgis-developer mailing list