[prev in list] [next in list] [prev in thread] [next in thread]
List: pykde
Subject: Re: [PyQt] PyQt-based Tetr*s
From: "Joshua Bronson" <jabronson () gmail ! com>
Date: 2008-03-26 20:51:29
Message-ID: 299cc2dd0803261351v7e81a571r663af2f4ac370917 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Mar 26, 2008 at 4:48 PM, Matt Newell <newellm@blur.com> wrote:
>
> >
> > Thanks Matt, that did the trick.
> >
> > Another question has come up. When implementing this in less
> sophisticated
> > Gui
> > frameworks<http://aipytris.googlecode.com/svn/trunk/aipytris/boardtk.py>,
> I
> > noticed that the canvas remembered primitives that had already been
> painted
> > on it, so on each paint event I only had to paint blocks that had moved
> > since the previous paint event, which I assume is more efficient. With
> my
> > Qt version, however, I am repainting every block on every paint event,
> even
> > ones that have not moved. Is there some way around this? I've looked at
> the
> > painting examples and read http://doc.trolltech.com/4.3/paintsystem.html
> ,
> > but I haven't found anything about whether QWidgets can retain state.
> >
> > Thanks,
> > Josh
>
>
> When you call QWidget::update, it considers the entire widget to be
> "dirty".
> By default is clears the dirty portion with the background color role.
> You
> can disable the clearing by calling QWidget::setAttribute with
> Qt::WA_OpaquePaintEvent or Qt::WA_NoSystemBackground(i'll leave it to you
> to
> decide which). Then you can keep track yourself what needs to be drawn.
>
> You can also limit the dirty region by calling update( QRect ) for each
> dirty
> rect. You can call update multiple times and it will only result in a
> single
> paint event, with all the rects joined into a QRegion.
>
> Matt
>
Thanks again Matt for the lightning-fast reply. That sounds like just the
info I need. I did a quick search for "NoSystemBackground" and found
http://doc.trolltech.com/qq/qq16-background.html. Is there any other
documentation you know of that you would recommend?
A bigger question is whether you think it's worth it. Things are working
just fine the way they are now, and at most each of my BoardQt instances is
only ever going to have to paint less than 20x9 = 180 QRects per paintEvent.
Am I likely to hit scaling problems any time soon if I have a multiplayer
game with several BoardQt instances painting at once? Is it worth doing it
the efficient way just on principle?
Thanks!
Josh
[Attachment #5 (text/html)]
<div class="gmail_quote">On Wed, Mar 26, 2008 at 4:48 PM, Matt Newell <<a \
href="mailto:newellm@blur.com">newellm@blur.com</a>> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"> <div class="Ih2E3d"><br>
><br>
> Thanks Matt, that did the trick.<br>
><br>
> Another question has come up. When implementing this in less sophisticated<br>
> Gui<br>
</div>> frameworks<<a \
href="http://aipytris.googlecode.com/svn/trunk/aipytris/boardtk.py" \
target="_blank">http://aipytris.googlecode.com/svn/trunk/aipytris/boardtk.py</a>>, \
I<br> <div class="Ih2E3d">> noticed that the canvas remembered primitives that had \
already been painted<br> > on it, so on each paint event I only had to paint \
blocks that had moved<br> > since the previous paint event, which I assume is more \
efficient. With my<br> > Qt version, however, I am repainting every block on every \
paint event, even<br> > ones that have not moved. Is there some way around this? \
I've looked at the<br> > painting examples and read <a \
href="http://doc.trolltech.com/4.3/paintsystem.html" \
target="_blank">http://doc.trolltech.com/4.3/paintsystem.html</a>,<br> > but I \
haven't found anything about whether QWidgets can retain state.<br> ><br>
> Thanks,<br>
> Josh<br>
<br>
<br>
</div>When you call QWidget::update, it considers the entire widget to be \
"dirty".<br> By default is clears the dirty portion with the background \
color role. You<br> can disable the clearing by calling QWidget::setAttribute \
with<br> Qt::WA_OpaquePaintEvent or Qt::WA_NoSystemBackground(i'll leave it to \
you to<br> decide which). Then you can keep track yourself what needs to be \
drawn.<br> <br>
You can also limit the dirty region by calling update( QRect ) for each dirty<br>
rect. You can call update multiple times and it will only result in a \
single<br> paint event, with all the rects joined into a QRegion.<br>
<font color="#888888"><br>
Matt<br>
</font></blockquote></div><br><div>Thanks again Matt for the lightning-fast reply. \
That sounds like just the info I need. I did a qui<span class="Apple-style-span" \
style="font-size: small;">ck search for "NoSystemBackground" and \
found <a href="http://doc.trolltech.com/qq/qq16-background.html">http://doc.trolltech.com/qq/qq16-background.html</a>. \
Is there any other documentation you know of that you would recommend?</span></div> \
<div><br class="webkit-block-placeholder"></div><div>A bigger question is whether you \
think it's worth it. Things are working just fine the way they are now, and at \
most each of my BoardQt instances is only ever going to have to paint less than 20x9 \
= 180 QRects per paintEvent. Am I likely to hit scaling problems any time soon if I \
have a multiplayer game with several BoardQt instances painting at once? Is it worth \
doing it the efficient way just on principle?</div> <div><br \
class="webkit-block-placeholder"></div><div>Thanks!</div><div><br \
class="webkit-block-placeholder"></div><div>Josh</div>
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic