Qt-interest Archive, March 2002
QCanvas Slowdown
Message 1 in thread
Hi, I am using a QCanvas to create a graph class that can plot x vs y on a
cartesian grid.
I am currently using QCanvasEllipse to represent each data point.
The problem comes into play when I have a domain of several hundred
thousand, and an associated Y value for each point in my domain. This
yields a canvas with several hundred thousand items, and calling
QCanvas::update() on a 1GHz Athlon takes on the order of 200
milliseconds. This is extremely poor performance on the canvas.
I know using a canvas to plot graphs may be overkill, as I can just
hand-plot to a QWidget, but I really like the ability to move around data
points at a whim, to 'stack' things in the Z depth, and other assorted
goodies that QCanvas offers by encapsulating each point in a discrete
object which can be manipulated, recolored, moved, transformed, and
generally mangled.
Any tips on how to get QCanvas to scale well? Should I be using canvas
rectangles instead of ellipses? I set my chunk size to the size of each
ellipse, but that didn't help much. :)
-Calin
Message 2 in thread
On Wed, 20 Mar 2002, Calin A. Culianu wrote:
> Hi, I am using a QCanvas to create a graph class that can plot x vs y on
> a cartesian grid.
>
>
> I am currently using QCanvasEllipse to represent each data point.
>
> The problem comes into play when I have a domain of several hundred
> thousand, and an associated Y value for each point in my domain. This
> yields a canvas with several hundred thousand items, and calling
> QCanvas::update() on a 1GHz Athlon takes on the order of 200
> milliseconds. This is extremely poor performance on the canvas.
>
I imagine a hundred thousand QCanvasEllipse objects may take up quite a
lot of memory. Compilers are generally not very good at allocating small
objects without wasting memory. Alexei Alezandrescu's book "Modern C++
Design" has a designated chapter on small object allocation. You could try
taking a look at this, derive from QCanvasEllipse and reimplement
new/delete. It might be the OS having a hard time running through a few
hundred megabytes of memory (modest overestimate :) referencing all those
canvasitems.
> I know using a canvas to plot graphs may be overkill, as I can just
> hand-plot to a QWidget, but I really like the ability to move around data
> points at a whim, to 'stack' things in the Z depth, and other assorted
> goodies that QCanvas offers by encapsulating each point in a discrete
> object which can be manipulated, recolored, moved, transformed, and
> generally mangled.
>
Yeah, I thought the Canvas was there for fast drawing. As I understand
from the documentation a QCanvas is the fastest method for drawing there
is in Qt. You could delve into the QCanvas code and see if there may be
some parts which you could strip out for your application. Derive and
reimplement.
> Any tips on how to get QCanvas to scale well? Should I be using canvas
> rectangles instead of ellipses? I set my chunk size to the size of each
> ellipse, but that didn't help much. :)
>
Maybe it would be an idea to derive from QCanvasItem and implement the
functionality you need? I can imagine that an ellipse might not be the
fastest thing to draw, and I'm also guessing that you actually only draw
circles. See if you can optimize the drawing functions.
As a side note: Have you tried using the plotter in Qwt to see how that
scales? It draws directly to a frame without using QCanvas, but maybe you
could some pointers from looking at the code...
Cheers,
--
[ signature omitted ]
Message 3 in thread
On Thu, 21 Mar 2002, Tarjei Knapstad wrote:
> On Wed, 20 Mar 2002, Calin A. Culianu wrote:
>
> > Hi, I am using a QCanvas to create a graph class that can plot x vs y on
> > a cartesian grid.
> >
> >
> > I am currently using QCanvasEllipse to represent each data point.
> >
> > The problem comes into play when I have a domain of several hundred
> > thousand, and an associated Y value for each point in my domain. This
> > yields a canvas with several hundred thousand items, and calling
> > QCanvas::update() on a 1GHz Athlon takes on the order of 200
> > milliseconds. This is extremely poor performance on the canvas.
> >
No it wasn't the creation of the Ellipses. That was very fast.. although
yes a valid optimization is pre-allocate them in a free pool and then
dispatch them to the canvas as needed, thus maximizing memory efficiency.
> I imagine a hundred thousand QCanvasEllipse objects may take up quite a
> lot of memory. Compilers are generally not very good at allocating small
> objects without wasting memory. Alexei Alezandrescu's book "Modern C++
> Design" has a designated chapter on small object allocation. You could try
> taking a look at this, derive from QCanvasEllipse and reimplement
> new/delete. It might be the OS having a hard time running through a few
> hundred megabytes of memory (modest overestimate :) referencing all those
> canvasitems.
>
> > I know using a canvas to plot graphs may be overkill, as I can just
> > hand-plot to a QWidget, but I really like the ability to move around data
> > points at a whim, to 'stack' things in the Z depth, and other assorted
> > goodies that QCanvas offers by encapsulating each point in a discrete
> > object which can be manipulated, recolored, moved, transformed, and
> > generally mangled.
> >
> Yeah, I thought the Canvas was there for fast drawing. As I understand
> from the documentation a QCanvas is the fastest method for drawing there
> is in Qt. You could delve into the QCanvas code and see if there may be
> some parts which you could strip out for your application. Derive and
> reimplement.
Well, it's not as fast as bitBlt'ing to a QWidget, but given how powerful
the QCanvas is, I tend to believe the claim that it is as fast as a
generic drawing module can get.. :)
>
> > Any tips on how to get QCanvas to scale well? Should I be using canvas
> > rectangles instead of ellipses? I set my chunk size to the size of each
> > ellipse, but that didn't help much. :)
> >
> Maybe it would be an idea to derive from QCanvasItem and implement the
> functionality you need? I can imagine that an ellipse might not be the
> fastest thing to draw, and I'm also guessing that you actually only draw
> circles. See if you can optimize the drawing functions.
>
> As a side note: Have you tried using the plotter in Qwt to see how that
> scales? It draws directly to a frame without using QCanvas, but maybe you
> could some pointers from looking at the code...
>
> Cheers,
>
Message 4 in thread
We've been developing on a PIII 600 mhz machine running mandrake 8 linux.
Our embedded platform is a 200 mhz national geode processor (similar to a
pentium 200 mhz) with 64 megs of ram. We recently tested some new code on
the embedded machine and we realized it runs extremely slow !! Its painfully
slow just displaying a new dialog box. Shouldn't a 200 mhz machine be
enough for simple windows and dialog boxes? I'm going to look into the
compiler flags, maybe its not optimizing...but I wanted to see if anyone had
run QT applications on a 200 mhz machine before.
Message 5 in thread
I have the same problem on a 200 MHz StrongARM. It is fast enough to be
useable, but much slower than I expected. Supposedly Qt 2.3 is faster,
and 3.x will be faster once they have optimized it.
Sean Marble
AMET, Inc.
sean_m@ametinc.com
-----Original Message-----
From: owner-qt-interest@trolltech.com
[mailto:owner-qt-interest@trolltech.com] On Behalf Of Omar
Sent: Thursday, March 21, 2002 10:17 AM
To: sean_m@ametinc.com
Subject: Slow performance QT 3.0.0 in Linux
We've been developing on a PIII 600 mhz machine running mandrake 8
linux. Our embedded platform is a 200 mhz national geode processor
(similar to a pentium 200 mhz) with 64 megs of ram. We recently tested
some new code on the embedded machine and we realized it runs extremely
slow !! Its painfully slow just displaying a new dialog box. Shouldn't
a 200 mhz machine be enough for simple windows and dialog boxes? I'm
going to look into the compiler flags, maybe its not optimizing...but I
wanted to see if anyone had run QT applications on a 200 mhz machine
before.
--
[ signature omitted ]
Message 6 in thread
Hmm this is definitely not good.....
----- Original Message -----
From: "Sean Marble" <sean_m@ametinc.com>
To: <qt-interest@trolltech.com>
Sent: Thursday, March 21, 2002 9:34 AM
Subject: RE: Slow performance QT 3.0.0 in Linux
> I have the same problem on a 200 MHz StrongARM. It is fast enough to be
> useable, but much slower than I expected. Supposedly Qt 2.3 is faster,
> and 3.x will be faster once they have optimized it.
>
> Sean Marble
> AMET, Inc.
> sean_m@ametinc.com
>
>
>
> -----Original Message-----
> From: owner-qt-interest@trolltech.com
> [mailto:owner-qt-interest@trolltech.com] On Behalf Of Omar
> Sent: Thursday, March 21, 2002 10:17 AM
> To: sean_m@ametinc.com
> Subject: Slow performance QT 3.0.0 in Linux
>
>
> We've been developing on a PIII 600 mhz machine running mandrake 8
> linux. Our embedded platform is a 200 mhz national geode processor
> (similar to a pentium 200 mhz) with 64 megs of ram. We recently tested
> some new code on the embedded machine and we realized it runs extremely
> slow !! Its painfully slow just displaying a new dialog box. Shouldn't
> a 200 mhz machine be enough for simple windows and dialog boxes? I'm
> going to look into the compiler flags, maybe its not optimizing...but I
> wanted to see if anyone had run QT applications on a 200 mhz machine
> before.
>
> --
> List archive and information: http://qt-interest.trolltech.com
>
> --
> List archive and information: http://qt-interest.trolltech.com
Message 7 in thread
I compiled with QT 2.3.1 and ran it on the same platform, and it is
definitely faster!! My co-workers also noticed their stuff runs faster
too, so now everyone wants to stick with 2.3.1 for now. In fact, one guy
was annoyed at me for upgrading us to 3.0.0 in the first place.... oh well
