rendering vectors got tremendously slow

[tutey@…]

It was way faster in 0.7.4. In 0.8, I could maybe live with displaying, but digitizing anything in 'Grass edit' is a pain - no exagaration, really.

Try 'Measure Area' tool, drawing a rectangle that encompasses the whole canvas - god-it-gets-slow. And it's only half that slow as digitizing in Grass edit is in average now.

I'm trying to understand it's only a defect due to some QT4 issue as Radim once explained, not a real QGIS bug, but the way it hampers productivity is really a big, as QGIS, is the only tool that let people digitize Grass vectors good, at least better and more stable than v.digit. But the slowness it now suffers make me cry. Is there any chance this could be fixed before releasing 0.8? I'm begging you, please?

Maciek

[wonder]

I have found an inefficiency regarding updates of rubberband in grass plugin and fixed that in r5878. Please give it a try and let us know whether the speed is fine now.

Btw. what's your computer configuration and what Qt version do you use? Because I have drawn a rectangle with measure area tool covering the whole canvas and it didn't suffer with any speed problems (with qgis maximized on 1280x1024 on AthlonXP 1,8ghz).

[tutey@…]

Hi

Thanks for taking care of this!

I have just built r5880. Unfortunatelly I can't notice any improvement after your patch. Both the measure area tool as well as the Grass edit still work really slow.

In case of the measure area tool, the slow-down in drawing the box is proportional to the area of the box. After I draw it's 3 corners in the corners of the map canvas, and start expanding the box (moving cursor to the 4th map canvas corner), the slowness is visible in it's whole.

In Grass edit the slowness seems propotional to the lenght of the line being currently rendered dynamically on the canvas. It doesn't depend on how many nodes, other features displayed or whatever. But, *interestingly*, it depends on the location of the 2 nodes of the dynamic line line on the canvas. To reproduce:

0. Turn off any layers you have displayed.

1. Create a new Grass vector.

2. In Grass edit: start a new line - placing the initial node in the *center* of the map canvas.

3. Move your cursor to one canvas corner and then around the canvas perimiter. Watch how the line is being rendered, following your cursor movements.

The *intersting* bit: rendering is slowest in the bottom-right corner, fastest (the least-sluggish I mean ;)) in the top-left corner and medium-slugish in 2 remainig corners of the map canvas. Though in each case the line lenght is the same, nothing else is displayed on the canvas and the Grass vector has no other features.

SPECS

Ubuntu Dapper, daily updated

machine: laptop, PM 1,86 GHz (Dothan), 1 GB 400 MHz RAM dual channel (2x512 MB), ATI X700 (128 MB)

display: 1280x800 32bit XORG 7.0, driver "radeon" (accelareted - 380 FPS in glxgears fulscreen)

qt: Dapper's stock 4.1.2

Maciek

[wonder]

This is weird. I can't reproduce anything from the stuff you're writing about. For me, measure area tool is reasonably fast, Grass digitizing is now also usable enough and that funny thing with different speeds of line rendering in Grass digitizing doesn't happen.

I suspect that it might be the problem of your Qt version - currently Qt4.1.4 is last stable version. Could you please try to upgrade to this version and let us know if things got better?

[tutey@…]

I could try newer QT. Maybe tomorrow. What version are you using?

Maciek

[wonder]

I'm using Qt4.1.4.

[anonymous]

I built QT 4.1.4 from source and QGIS SVN r5885 against it. Still the problems I'm describing above apply - exactly the way I describe them.

On another laptop (also pretty modern and fast) same things happen.

Are you sure you are trying to reproduce my steps exactly the way I describe it? Any doubts I could give you a hand with?

Maciek

[wonder]

I'm sorry, I've followed your steps again with the same result (ie. it works well for me).

I wonder where might be the problem. Do you have RENDER extension turned on in your X server? If not, this might be the performance killer. You can check it with:

xdpyinfo | grep RENDER

Also do you have a chance to try QGIS on Windows or Mac OS X to find out whether it's just X11 related problem?

[tutey@…]

xdpyinfo | grep RENDER
    RENDER

So it's turned on.

I could try on Windows XP later. What system are you using?

[wonder]

Hmm :-/ I'm using Gentoo Linux and sometimes Windows XP.

[tutey@…]

Hi. Wanting to get the version for windows I went to QGIS donload section and there is no any 0.8 for win there. The torrents at ​http://download.qgis.org/torrents/ are dead.

Only by accident I went to news section and found a link to 0.8 for windows there. Downloading now, will let you know later how it worked. But please tell someone in cahrge to add that link to dowloads page too. I'm contacting you via trac as I don't have access to my email now and I don't want to forget that if left foir later. Hope that's OK.

Cheers, Maciek

[tutey@…]

Hi,

I checked the http://qgis.org/uploadfiles/qgis-0.8.0_Preview-2.zip on Windows XP home, on the same machine and the problem is not present! Both 'measure area' and Grass edit work at a resonable pace, several times faster than on my Ubuntu Dapper. I wish iyt worked that smooth on my Linux! Any other suggestions what the problem could be? GNOME?

Now that I look at the pace the other windows are rendered, I guess they are quite slow, at least compared to Windows. Hmm. Any hints? I'll try to play with xorg.conf and Google for something. Maybe ATI binary driver will perform better (I've been using 'radeon' accelerated X's stock driver for ATI Radeon).

Maciek

[tutey@…]

Allright! Switching to ATI's binary 'fglrx' 8.28.8 driver fixed the preoblem. Al the drawing in qgis 0.8 SVN is much boosted when compared to 'radeon'. dAMN i'M GLAD!

Xorg's 'radeon' is the default driver when one installs Ubuntu Dapper. It worked fast enough for me not to have noticed any slowdown till I tried qgis 0.8 (though now I see it was slow in other apps too, when compared to 'fglrx'). This means that any other Ubuntu Dapper user with modern ATI's graphics might suffer the same problems as I did, and he is likely to blame qgis (in error) for the sluggish, severe slowdowan (it is *really* that bad using 'radeon'). Is there any way qgis could recognize the eventul problem and aid the user with a note like "You are using ATI graphics with 'radeon' driver. If you suffer from severe rendering slowdown in qgis, please consider switching to ATI's propriearty 'flgrx' driver. ​http://seveas.theplayboymansion.net/seveas/dists/dapper-seveas/drivers/ provides up-to-date precompiled packages for easy install."

Just a thought. I don't want folks to blame qgis for a problem it's not guilty for, like I did. I want folks to like qgis performance.

Cheers, Maciek

[wonder]

Great to hear that it's finally working for you!

It might be good to check the driver used in X server, but I don't know how to do it, anyone knows? Probably a mention about this in forums or other place would be enough. However I still can't believe that the difference between the drivers is so big.

Can we close the ticket?

[tutey@…]

Believe it or not but the difference is tremenodus. I don't know what is exactly the mechanism here. All I can say that when I use Driver "radeon" the GRASS edit is so slow that is technically impossible to use it for real life digitizing. When I switch to Driver "fglrx" the pace is OK tough.

I should mention that until recently (ie. before Ubuntu Dapper) I've been using always the "fglrx" driver, because it was the only driver for ATI cards that provided hardware 3D acceleration (in past the open source "radeon" driver was very poor for 3D). However, when in Dapper new, *3D accelerated* version of "radeon" was shipped, and it performed very well in glxgears, I decided to quit the propriarty "fglrx". And I didn't see any side effects that would trigger my attention until this obvious, unberable sluggishnes of GRASS Edit (and of the area measure tool) in QGIS. As the QGIS version I noticed the problem for was 0.8, and I never had the problem in 0.7/QT3, I blamed that on... QGIS or QT4. Now knowing all that drivers stuff I should try 0.7 with "radeon" and "fglrx" and see what happens. If time allows I will, but not very soon.

You decide to close the bug or not. I just can't say if this is a bug in the "radeon" driver, XORG, QT or QGIS. But I do see that GRASS Edit is way to slow for normal work with driver "radeon" and OK with "fglrx". And I can reproduce this pattern on two laptops with ATI Mobile graphics - my is the X700 model and the other is X600.

Maciek

[g_j_m]

I'll close it... Looks not to be a problem with qgis itself

[anonymous]

I had enough time to sort this thing for good today. Final notes:

1. Like I said, using ATI's 'fglrx' driver instead of XORG's 'radeon' improves the 2D performance so that the discussed slow-down in QGIS vanishes. However, the 3D performance goes down about 20 (!) times using fglrx on my ATI X700, despite *no errors* in the XORG's logs and direct rendering enabled *for sure*. This might be not acceptable for many folks, including me.

2. I switched back to 'radeon' driver (removing *all the bits of radeon* and *rebooting* first) which provides a decent 3D. Found out that Ubuntu Dapper uses XAA acceleration method by default. Tried old "good" EXA instead by adding to graphics card's Section "Device":

Option "AccelMethod" "EXA"

in xorg.conf. This reduced the 3D about 30%, but 2D was improved greatly and the discussed problem in QGIS vanished. Quite a compromise - fully working QGIS (and other 2D stuff) at the expense of some, but accpetable for, me 3D loss.

3. Finally, I found out that the compromise is not necessary. Removed the EXA mode enforcement and added the following line to xorg.conf (graphics card's Section "Device"):

Option "XaaNoOffscreenPixmaps"

This prevents any tearing and slow downs in 2D, including problems with QGIS, *and* doesn't do any harm to 3D in XAA mode. Perfect.

Summarising:

1. 2D OK, 3D sucks:

    Driver "fglrx"
   

2. 2D OK, 3D slower - but acceptable:

   Driver "radeon"
   Option "AccelMethod" "EXA"
   

3. 2D and 3D OK:

   Driver "radeon"
   Option "XaaNoOffscreenPixmaps"
   

I hope this helps in case anyone gets into the troubles I had.

Cheers, Maciek

[tutey@…]

Update: the flgrx driver version 8.25.18 performs OK both in 3D and 2D! The problem with 2D, described in point 1 of my previous message, refers to driver version 8.28.8 only. More good news is that the "good" 8.25.18 version is the stock's Ubuntu Dapper one. The "buggy" 8.28.8 one was from a different source.

Maciek

[(none)]

Milestone Version 0.8 deleted