QGraphicsScene performance

Hi,
I just did a small test with a QGraphicsScene with a few
balls bouncing 
around, I noticed that with about 10 balls it starts
becoming slow on my 
system (using 100% of my cpu), while on the Windows computer
of my roommate 
it seems to take more than twice that amount, but but his
computer should 
actuallll be sower than mine, so I was wondering what was
causing the 
difference, does the painting take advantage of graphic
hardware 
acceleration? Because that could explain it (damn ATI that
doesn't provide 
proper drivers...).
Another thing I noticed was that turning on antialiasing or
not don't seem to 
make any difference at all: what does that mean? Just that
the antialiasing 
code is very efficient? It the beginning I thought that it
could mean that 
the resources weren't used for the painting, but when the
window is hidden it 
uses 0% cpu, so I suppose it must be the painting, or am I
missing something?
At the end I thing I will just use QGraphicsScene for
KBreakout, after all I 
don't think there is need to have more than two balls at a
time very ofter 
and a few bonus objects falling down. We have to be just a
bit carefull to 
not write _to_ crazy levels...
bye,
- Fela
-- 
Hello! I'm a signature virus. Copy me to your signature, ^^
pleeeeease!!!!!!
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Fri, 29 Jun 2007 02:35 am, Fela Winkelmolen wrote:
> I just did a small test with a QGraphicsScene with a
few balls bouncing
> around, I noticed that with about 10 balls it starts
becoming slow on my
> system (using 100% of my cpu), while on the Windows
computer of my roommate
> it seems to take more than twice that amount, but but
his computer should
> actuallll be sower than mine, so I was wondering what
was causing the
> difference, does the painting take advantage of graphic
hardware
> acceleration? Because that could explain it (damn ATI
that doesn't provide
> proper drivers...).
>
Did you try export QT_FLUSH_PAINT=1?  It can make the
reasons for
these things visible.  IIRC, Windows is expected (by
Trolltech) to be
inherently faster because there is no tic-tacking with the
X-server.
In Windows versions of Qt, as I understand it, QImage and
QPixmap
forms of a graphic are equivalent.  In Linux/Unix, pixmaps
are held
in the X-server and there is much to-ing and fro-ing during
rapid
changes in the graphics or conversions of QImage.  The
bigger the
area to be updated, the worse it gets.  Try running the
"top" command
while your test executes.  You should see X coming to the
top of the
list.  Anyway, that's what was happening with Qt 4.0 and
KGoldrunner
about 6 months ago.  Graphics cards do not seem to have a
great
bearing on this.  Mine is always off in Linux (no driver
installed).

> At the end I think I will just use QGraphicsScene
> for KBreakout, after all I don't think there is need to
have more than two
> balls at a time very ofter and a few bonus objects
falling down. We have to
> be just a bit carefull to not write _to_ crazy
levels...
>
Yes.  That's reasonable.  KGoldrunner with KGV was failing
on just
a small percentage of levels and the timing was out of whack
in some
existing levels, but we would have had to find all those
levels, among
200 or so, and delete them ... :-(  We also have to consider
people
in the world who do not have multi-GHz machines.

All the best with KBreakout, Ian W.
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

Perhaps you could consider using SDL. It integrates with Qt
and is
cross platform. I would expect the performance to be
better.

It makes me a bit sad when people said they have a port of a
game that
could run on antique computers but face performance issues
today.

"after all I don't think there is need to have more
than two balls at
a time very ofter and a few bonus objects falling
down"
"We also have to consider people in the world who do
not have
multi-GHz machines."

This could be on bash.org, or slashdot 
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

Fela Winkelmolen wrote:
> I just did a small test with a QGraphicsScene with a
few balls bouncing 
> around, I noticed that with about 10 balls it starts
becoming slow on my 
> system (using 100% of my cpu)

(Note: Fela, this is not directed at you .)
Granted, I don't have any firsthand experience with this
stuff, but that 
seems... surprising. Ten years ago we had games with
multi-parallax 
backgrounds and dozens, if not hundreds, of sprites (ok,
granted this 
was in 320x200 resolution)... and now ten wimpy sprites are
bringing 
computers to their knees?

I'm with Jeremy; what am I missing here?

> At the end I thing I will just use QGraphicsScene for
KBreakout, after all I 
> don't think there is need to have more than two balls
at a time very ofter 
> and a few bonus objects falling down.

You haven't played Electranoid, have you?  It is my
secret desire to 
let you do the first part of a KDE port of that  (also
since I 
currently don't have the resources to delve into games on
KDE). Ten 
moving objects would not be unusual at all for that.

-- 
Mathew
(sorry, .sig file is on the other computer)

_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

I am thinking maybe you could make your code available
somewhere, if
there is something you are missing somebody more experienced
will
point it out.

Myself i would like to see.

Also i wonder if "scalable" really is good idea
for "arcade" games.
First these games are best played fullscreen, and i wonder
what would
be the performance on a 1600 pix or more display (not
uncommon on
newer configurations), the pixmaps would be huge.
Note that i don't mean scalability could not be used, on the
contrary
it is a good way to provide sprites that adapt low and high
resolutions. But there the steps are well defined.

Second performance greatly affects gameplay, especially on a
breakout
game. GFX are sound are also important added value.

If think that if i were to make a breakout game nowadays i
would go OpenGL.
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Fri, 29 Jun 2007 11:26 am, Jeremy Wick wrote:
> It makes me a bit sad when people said they have a port
of a game that
> could run on antique computers but face performance
issues today.
>
I once headed a software project in which a computer of
about 0.8MHz
and 0.192Mb of RAM handled 300 online terminals and 40
transactions
per second for over an hour, at peak time.  Now I have a
machine 2000
times faster and with more than 1000 times as much RAM, that
has had
exactly the troubles you describe.

You have heard of Grosch's Law and Moore's Law ... well I
call this
the law of Software Obesity.  It is an extension of
Parkinson's Law
of business (work expands to fill the time available for its
completion).
In this case, software expands to fill the memory and CPU
power
available.  I know, my machine is doing a lot of heavy
graphics, but
it only starts to sweat computationally if I run XaoS
fractal zoomer
on auto (zooming into the infinite recesses of the
Mandelbrot set).

Dinosaurially yours, Ian W. 
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Fri, 29 Jun 2007 02:02 pm, Matthew Woehlke wrote:
> Fela Winkelmolen wrote:
> > I just did a small test with a QGraphicsScene with
a few balls bouncing
> > around, I noticed that with about 10 balls it
starts becoming slow on my
> > system (using 100% of my cpu)
>
> Ten years ago we had games with multi-parallax
> backgrounds and dozens, if not hundreds, of sprites
(ok, granted this
> was in 320x200 resolution)... and now ten wimpy sprites
are bringing
> computers to their knees?
>
I don't think this is something in Fela's code.

Try the following experiment.  In your KDE4/Qt4 environment,
run:

   $QTDIR/examples/graphicsview/portedcanvas/portedcanvas

This is one of the QGV examples.  Resize the window so that
all
the static objects are in view.  In another window, start a
"top"
command.  In the ported canvas window, hold down the Alt
key
and type an "s" character 10 times.  That starts
10 QGV sprites.
Now I think you will see, in the "top" window,
huge CPU usage
for processes "portedcanvas" and "X".

If you run "QT_FLUSH_PAINT=1 above_command" you
will see
the sprites flicker yellow as they are updated.  In Qt 4.0,
that
update would also cover other objects and large areas of
background between the sprites.  That was the
"bounding
rectangle" problem.  Now, in Qt 4.3, that overhead
seems to
have been replaced by another (less visible) one ... 

All the best, Ian W.

PS. KGameCanvas *will* handle sprites efficiently.  One of
my
KGoldrunner levels has 26 of them and the CPU usage is still
low.
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

> Granted, I don't have any firsthand experience with
this stuff, but that
> seems... surprising. Ten years ago we had games with
multi-parallax
> backgrounds and dozens, if not hundreds, of sprites
(ok, granted this
> was in 320x200 resolution)... and now ten wimpy sprites
are bringing
> computers to their knees?
>
> I'm with Jeremy; what am I missing here?

As you mentioned in the start of your message, you are
missing experience
with QGV, its strengths and weaknesses 

This is something we (Ian and me) raised last year, since
the initial QGV
porting effort started on KDE Games, with KGoldrunner.
Performance on X is
better in 4.3 compared with 4.0, and I like to think our
feedback could
have contributed to it 

But depending on the update pattern you will still see
performance issues
when large areas are updated, specially if you are using a
scaled scene.
There were code posted (the initial KGoldrunner port) and
discussion about
this on both kde-games-devel and qt4-preview, starting in
September of
last year, under several threads. Search for KGoldrunner in
the mailing
list archives around these dates. There was profiling done,
and Andreas
was kind enough to devote some time during last year's
aKademy in Dublin
to attempt to solve the issue in a debugging session at the
hacking labs.

This is the reason why some games use KGameCanvas, and
others use QGV.
Notice that these bottlenecks are only apparent when the
conditions
mentioned above exist: large number of sprites updating a
large area of
the scene (more than 20 update rects collected), running on
X11, and this
is made worse when QGraphicsScene dimensions do not match
the
QGraphicsView size (transformation is active.) Most games in
our module
run happily in QGV and benefit from its convenient API,
others have to run
KGameCanvas in order to achieve better performance and lower
cpu usage.

Just try the examples included with Qt and you will see the
same issue if
you add enough mice to the collided mice one, or the ported
canvas.

Regards,
Mauricio Piacentini



_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Fri 29 Jun 2007 03:36, Ian Wadham wrote:
> You have heard of Grosch's Law and Moore's Law ... well
I call this
> the law of Software Obesity.  It is an extension of
Parkinson's Law
> of business (work expands to fill the time available
for its completion).

It is usually referred to as Nathan's First Law of Software

(htt
p://research.microsoft.com/ACM97/nm/sld026.htm) --
"software is a gas, 
it expands to fit the container it is in". There is a
somewhat better 
explanation of the law on 
http://www.codinghorror.com/blog/archives/000677.html
.

-- 
	Henrique Pinto
	tawhakigmail.com
_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel

Hi, thanks for all the feedback,

I've attached the simple test i did, just click to make a
ball appear (scene.h 
contains some constants to change the basic
"settings"). At 13 balls it 
starts to use 100% cpu on my one year old laptop (it was 10
last time because 
I was using ssh for my kde4 account... realized it only when
running top, and 
yes half of the cpu is used by X)

Setting "export QT_FLUSH_PAINT=1" the result is
what you expect it to be. 
I would also think that painting everything manually (like
int the cannongame 
Qt tutorial, I hope you understand what I mean) you get the
same performance, 
or am I missing something? What about using KGameCanvas?
I mostly discarted openGL/SDL because I thought kdegames
don't want those 
dependencies, and I want to write this game as a starting
point to contribute 
to KDE, to learn the KDE technologies and to get to know the
community, etc.

bye,
- Fela
-- 
Hello! I'm a signature virus. Copy me to your signature, ^^
pleeeeease!!!!!!

_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel