rendering current line in Grass digitizer is very slow

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

rendering current line in Grass digitizer is very slow

Maciek Sieczka
Hi,

Lines in Grass digitizer are being drawn really slowly on pretty fast
computers [1]. The more vertices the line has, the slower the
rendering. The bug affects only the line being currently digitized, ie.
if you just try to modify an existing one by moving or adding
single vertices rendering is fast. But when you digitize a long line,
with each vertex added the rendering speed decreases.

To reproduce:

1. Open a Grass vector in Grass digitizer.
2. Start a new line (or boundary) by putting the first vertex. See how
smoothly the line is drawn as you move the cursor with mouse.
3. Now digitize 10, 100, 300 etc. vertices. See how much slower the
rendering gets with each vertex put. Note the slow-down does not depend
on the zoom level or the amount of features being displayed. The only
"reason" for the slow-down is the amount of vertices you have put in
the line being currently digitized.

Is this a known issue? Is my description clear? Could it be fixed?

Using SVN 0.8 of yesterday, Ubuntu Breezy and Dapper.

Maciek

[1]
PM 1,86 GHz, ATI X700 128MB, propriearty drivers, direct rendering on
AMD 3200, NVIDIA GX400 64MB, propriearty drivers, direct rendering on

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: rendering current line in Grass digitizer is very slow

Radim Blazek-2
GRASS edit in 0.8 is using QgsRubberBand (XOR rendering
does not work anymore IIRC) and it is probably slow because
it is not designed for complex graphics.
I dont know if it can be improved.

Radim


On 7/7/06, Maciek Sieczka <[hidden email]> wrote:

> Hi,
>
> Lines in Grass digitizer are being drawn really slowly on pretty fast
> computers [1]. The more vertices the line has, the slower the
> rendering. The bug affects only the line being currently digitized, ie.
> if you just try to modify an existing one by moving or adding
> single vertices rendering is fast. But when you digitize a long line,
> with each vertex added the rendering speed decreases.
>
> To reproduce:
>
> 1. Open a Grass vector in Grass digitizer.
> 2. Start a new line (or boundary) by putting the first vertex. See how
> smoothly the line is drawn as you move the cursor with mouse.
> 3. Now digitize 10, 100, 300 etc. vertices. See how much slower the
> rendering gets with each vertex put. Note the slow-down does not depend
> on the zoom level or the amount of features being displayed. The only
> "reason" for the slow-down is the amount of vertices you have put in
> the line being currently digitized.
>
> Is this a known issue? Is my description clear? Could it be fixed?
>
> Using SVN 0.8 of yesterday, Ubuntu Breezy and Dapper.
>
> Maciek
>
> [1]
> PM 1,86 GHz, ATI X700 128MB, propriearty drivers, direct rendering on
> AMD 3200, NVIDIA GX400 64MB, propriearty drivers, direct rendering on
>
> --------------------
> W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
> http://katalog.panoramainternetu.pl/
>
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: rendering current line in Grass digitizer is very slow

Maciej Sieczka - old
Radim Blazek napisał(a):
> GRASS edit in 0.8 is using QgsRubberBand (XOR rendering
> does not work anymore IIRC) and it is probably slow because
> it is not designed for complex graphics.
> I dont know if it can be improved.

Digitizing Grass vectors is too slow for production in 0.8. I'll have to
get back to 0.74, in spite of it's own bugs.

Too bad, 0.8 has so many other advantages...

Best,
Maciek
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: rendering current line in Grass digitizer is very slow

Stephan Holl-2
In reply to this post by Radim Blazek-2
Hello,

On Mon, 10 Jul 2006 11:00:09 +0200 "Radim Blazek"
<[hidden email]> wrote:

> GRASS edit in 0.8 is using QgsRubberBand (XOR rendering
> does not work anymore IIRC) and it is probably slow because
> it is not designed for complex graphics.
> I dont know if it can be improved.

Is there any chance to make this working as it was in 0.7.4 also with
qt4, probably before 0.8 will be stable?

I am with Macieks opinion that this should work well in 0.8.

Best
        Stephan

>
> Radim
>
>
> On 7/7/06, Maciek Sieczka <[hidden email]> wrote:
> > Hi,
> >
> > Lines in Grass digitizer are being drawn really slowly on pretty
> > fast computers [1]. The more vertices the line has, the slower the
> > rendering. The bug affects only the line being currently digitized,
> > ie. if you just try to modify an existing one by moving or adding
> > single vertices rendering is fast. But when you digitize a long
> > line, with each vertex added the rendering speed decreases.
> >
> > To reproduce:
> >
> > 1. Open a Grass vector in Grass digitizer.
> > 2. Start a new line (or boundary) by putting the first vertex. See
> > how smoothly the line is drawn as you move the cursor with mouse.
> > 3. Now digitize 10, 100, 300 etc. vertices. See how much slower the
> > rendering gets with each vertex put. Note the slow-down does not
> > depend on the zoom level or the amount of features being displayed.
> > The only "reason" for the slow-down is the amount of vertices you
> > have put in the line being currently digitized.
> >
> > Is this a known issue? Is my description clear? Could it be fixed?
> >
> > Using SVN 0.8 of yesterday, Ubuntu Breezy and Dapper.
> >
> > Maciek
> >
> > [1]
> > PM 1,86 GHz, ATI X700 128MB, propriearty drivers, direct rendering
> > on AMD 3200, NVIDIA GX400 64MB, propriearty drivers, direct
> > rendering on
> >
> > --------------------
> > W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie
> > tylko najlepsze z nich! http://katalog.panoramainternetu.pl/
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > [hidden email]
> > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
> >
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer



--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office      -     Mengendamm 16d      -     D-30177 Hannover
Internet: www.gdf-hannover.de      -      Email: [hidden email]
Phone : ++49-(0)511.39088507       -        Fax: ++49-(0)511.39088508
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: rendering current line in Grass digitizer is very slow

Radim Blazek-2
In reply to this post by Maciej Sieczka - old
On 7/13/06, Maciej Sieczka <[hidden email]> wrote:
> Radim Blazek napisał(a):
> > GRASS edit in 0.8 is using QgsRubberBand (XOR rendering
> > does not work anymore IIRC) and it is probably slow because
> > it is not designed for complex graphics.
> > I dont know if it can be improved.
>
> Digitizing Grass vectors is too slow for production in 0.8. I'll have to
> get back to 0.74, in spite of it's own bugs.

Can you be more specific what is slow? Drawing the map,
editing a line, ...?

Radim

> Too bad, 0.8 has so many other advantages...
>
> Best,
> Maciek
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: rendering current line in Grass digitizer is very slow

Maciej Sieczka - old
Radim Blazek napisał(a):

> On 7/13/06, Maciej Sieczka <[hidden email]> wrote:
>> Radim Blazek napisał(a):
>> > GRASS edit in 0.8 is using QgsRubberBand (XOR rendering
>> > does not work anymore IIRC) and it is probably slow because
>> > it is not designed for complex graphics.
>> > I dont know if it can be improved.
>>
>> Digitizing Grass vectors is too slow for production in 0.8. I'll have to
>> get back to 0.74, in spite of it's own bugs.
>
> Can you be more specific what is slow? Drawing the map,
> editing a line, ...?

Rendering *everything* gets slower and slower as you put new vertices
when digitizing line or boundary. For that you can't zoom/pan
efficiently. I have described how to reproduce the problem in my initial
email in this thread.

Maciek

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: rendering current line in Grass digitizer is very slow

Maciej Sieczka - old
In reply to this post by Radim Blazek-2
Radim Blazek wrote:
> GRASS edit in 0.8 is using QgsRubberBand (XOR rendering
> does not work anymore IIRC) and it is probably slow because
> it is not designed for complex graphics.
> I dont know if it can be improved.

Guys,

I don't know how actuall Radim's comment is currently, but I want to
let all QGISers know that the main (if not the only) reason for the
slowdown I suffered from were Ubuntu Dapper's *default* XORG settings
for ATI cards. You can find a solution to the problem in my last post
in the https://svn.qgis.org/trac/ticket/295.

In short, if using the Dapper's default settings for ATI graphics,
which are driver 'radeon' and XAA accel mode, and suffering from
slow-downs in 2D graphics, you should add:

Option "XaaNoOffscreenPixmaps"

to your xorg.conf.

Without this tweak the performance of my X700 (and X600 on another
machine) ATI board was sluggish in 2D, but somehow bearable until I
noticed it in QGIS. That's why I blamed it on QGIS at first. Sorry for
the fuss. It seems QGIS has nothing to do with it.

Cheers,
Maciek
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer