<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Qt: Improving QGraphicsView Performance</title>
	<atom:link href="http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/feed/" rel="self" type="application/rss+xml" />
	<link>http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/</link>
	<description>Your blog is probably better than mine.</description>
	<pubDate>Wed, 19 Nov 2008 04:41:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: codercpp1981</title>
		<link>http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-53135</link>
		<dc:creator>codercpp1981</dc:creator>
		<pubDate>Tue, 01 Jul 2008 05:13:08 +0000</pubDate>
		<guid isPermaLink="false">http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-53135</guid>
		<description>Hi Dave,

I am facing a problem with QGraphicsView framework. I am using QGraphicsPixmapItem for drawing image on View. To prevent it from the zooming functionality i.e increasing it's size when zoomedIn , I have used flag setFlag(QGraphicsItem::ItemIgnoresTransformations); but it's not working.
I have posted a thread on QTCenter Forum and for detailed description you can see it.

http://www.qtcentre.org/forum/f-qt-programming-2/t-problem-with-qgraphicsview-and-itemignorestransformations-14400.html

If you have any suggestion plz let me know.

Thanks</description>
		<content:encoded><![CDATA[<p>Hi Dave,</p>
<p>I am facing a problem with QGraphicsView framework. I am using QGraphicsPixmapItem for drawing image on View. To prevent it from the zooming functionality i.e increasing it&#8217;s size when zoomedIn , I have used flag setFlag(QGraphicsItem::ItemIgnoresTransformations); but it&#8217;s not working.<br />
I have posted a thread on QTCenter Forum and for detailed description you can see it.</p>
<p><a href="http://www.qtcentre.org/forum/f-qt-programming-2/t-problem-with-qgraphicsview-and-itemignorestransformations-14400.html" rel="nofollow">http://www.qtcentre.org/forum/f-qt-programming-2/t-problem-with-qgraphicsview-and-itemignorestransformations-14400.html</a></p>
<p>If you have any suggestion plz let me know.</p>
<p>Thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew</title>
		<link>http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-45281</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Wed, 16 Apr 2008 10:33:44 +0000</pubDate>
		<guid isPermaLink="false">http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-45281</guid>
		<description>Thanks for the suggestions. Another thing I've noticed is that drawing lines with line patterns can be very slow by default. The trick here is to enable "cosmetic line widths". See QPen::setCosmetic(...);

Unfortunately, that also means that line widths are no longer scaled with the graphics view, so we have to do that manually now for example in QGraphicsView::drawItems(...);

This solution provided the performance boost we needed to make the whole graphics view framework usable for our needs.</description>
		<content:encoded><![CDATA[<p>Thanks for the suggestions. Another thing I&#8217;ve noticed is that drawing lines with line patterns can be very slow by default. The trick here is to enable &#8220;cosmetic line widths&#8221;. See QPen::setCosmetic(&#8230;);</p>
<p>Unfortunately, that also means that line widths are no longer scaled with the graphics view, so we have to do that manually now for example in QGraphicsView::drawItems(&#8230;);</p>
<p>This solution provided the performance boost we needed to make the whole graphics view framework usable for our needs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Veeranjaneyulu</title>
		<link>http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-37387</link>
		<dc:creator>Veeranjaneyulu</dc:creator>
		<pubDate>Sat, 16 Feb 2008 11:51:54 +0000</pubDate>
		<guid isPermaLink="false">http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-37387</guid>
		<description>This is veeru , i am working on this same problem.

 So , i will try your solutin.

 Thanks

Regards
Veeru</description>
		<content:encoded><![CDATA[<p>This is veeru , i am working on this same problem.</p>
<p> So , i will try your solutin.</p>
<p> Thanks</p>
<p>Regards<br />
Veeru</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mac [unlesbar]</title>
		<link>http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-31498</link>
		<dc:creator>Mac [unlesbar]</dc:creator>
		<pubDate>Fri, 16 Nov 2007 16:55:10 +0000</pubDate>
		<guid isPermaLink="false">http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-31498</guid>
		<description>A thing worth mentioning, though it has nothing to do with "manual" optimization, is the fact that debug builds of Qt4 apps using QGraphicsView are damn slower than retail builds. Of course one expects a slowdown in debug builds but in my case it really looked like a design issue.

However, thanks for your excellent article! Instant bookmark!</description>
		<content:encoded><![CDATA[<p>A thing worth mentioning, though it has nothing to do with &#8220;manual&#8221; optimization, is the fact that debug builds of Qt4 apps using QGraphicsView are damn slower than retail builds. Of course one expects a slowdown in debug builds but in my case it really looked like a design issue.</p>
<p>However, thanks for your excellent article! Instant bookmark!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave</title>
		<link>http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-7241</link>
		<dc:creator>Dave</dc:creator>
		<pubDate>Sun, 25 Feb 2007 15:48:30 +0000</pubDate>
		<guid isPermaLink="false">http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-7241</guid>
		<description>Thanks for the comment Cyril.

Yes, your approach works well when there are many moving QGraphicsItems on the screen at once, and works at the QGraphicsView level. 

On the other hand, my optimization was at the QGraphicsItem level, and works well when only a subset of items are moving.

In fact, your optimization combined with mine would provide excellent handling of many, small QGraphicsItems moving all at once.

Thanks!

--Dave</description>
		<content:encoded><![CDATA[<p>Thanks for the comment Cyril.</p>
<p>Yes, your approach works well when there are many moving QGraphicsItems on the screen at once, and works at the QGraphicsView level. </p>
<p>On the other hand, my optimization was at the QGraphicsItem level, and works well when only a subset of items are moving.</p>
<p>In fact, your optimization combined with mine would provide excellent handling of many, small QGraphicsItems moving all at once.</p>
<p>Thanks!</p>
<p>&#8211;Dave</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cyril</title>
		<link>http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-7215</link>
		<dc:creator>Cyril</dc:creator>
		<pubDate>Sun, 25 Feb 2007 06:04:44 +0000</pubDate>
		<guid isPermaLink="false">http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/#comment-7215</guid>
		<description>Hi Dave,

Thanks for your Tricks, they can help a lot,
I would like to speek about avoiding painting :
-Avoiding unecessary paintings is a great idea, the purpose is, i imagine, to save time in order to make drawing as ligth as possible.
But it can become an illusion, like it is in Qt4, for certain cases, items with simple shapes, a lot of times is spent to avoid spending few milliseconds:

in Qt4, there are two ways of redrawing :

Using BSP tree, in wich case each modification to the draw should update the BSP tree, making the intersection computing between the items and the region to update unecessary.
The classical way, in wich you need to compute this intersection.

In the second case, Qt is very inefficient, as it compute the intersection between each item and each rect of the region to update
imagine; in a qregion you can find 500 rects, so with 500 items, it makes
250000 intersections to compute, do you really think it is faster then redrawing 500 items?
To have a good idea about that, if you have a program with a lot of items, you can make an experience:
Instead of QGraphicsView, use a sub class, MyFasterGraphicView :

class MyFasterGraphicView :public QGraphicsView
{
 	Q_OBJECT
public:
	MyFasterGraphicView( ...);
protected:
	...
	void paintEvent ( QPaintEvent * event );
	...
};

void MyFasterGraphicView::paintEvent ( QPaintEvent * event )
{
	QPaintEvent *newEvent=new QPaintEvent(event-&#62;region().boundingRect());
	QGraphicsView::paintEvent(newEvent);
	delete newEvent;
}

So the question is:
what is better? bad results with good intentions, or better results with bad workarounds?
And keep me updated, :)
Regards,

Cyril
Ps: this "workaround" have a great result with the collidingmices example delivered in the Qt4 distribution, at full screen</description>
		<content:encoded><![CDATA[<p>Hi Dave,</p>
<p>Thanks for your Tricks, they can help a lot,<br />
I would like to speek about avoiding painting :<br />
-Avoiding unecessary paintings is a great idea, the purpose is, i imagine, to save time in order to make drawing as ligth as possible.<br />
But it can become an illusion, like it is in Qt4, for certain cases, items with simple shapes, a lot of times is spent to avoid spending few milliseconds:</p>
<p>in Qt4, there are two ways of redrawing :</p>
<p>Using BSP tree, in wich case each modification to the draw should update the BSP tree, making the intersection computing between the items and the region to update unecessary.<br />
The classical way, in wich you need to compute this intersection.</p>
<p>In the second case, Qt is very inefficient, as it compute the intersection between each item and each rect of the region to update<br />
imagine; in a qregion you can find 500 rects, so with 500 items, it makes<br />
250000 intersections to compute, do you really think it is faster then redrawing 500 items?<br />
To have a good idea about that, if you have a program with a lot of items, you can make an experience:<br />
Instead of QGraphicsView, use a sub class, MyFasterGraphicView :</p>
<p>class MyFasterGraphicView :public QGraphicsView<br />
{<br />
 	Q_OBJECT<br />
public:<br />
	MyFasterGraphicView( &#8230;);<br />
protected:<br />
	&#8230;<br />
	void paintEvent ( QPaintEvent * event );<br />
	&#8230;<br />
};</p>
<p>void MyFasterGraphicView::paintEvent ( QPaintEvent * event )<br />
{<br />
	QPaintEvent *newEvent=new QPaintEvent(event-&gt;region().boundingRect());<br />
	QGraphicsView::paintEvent(newEvent);<br />
	delete newEvent;<br />
}</p>
<p>So the question is:<br />
what is better? bad results with good intentions, or better results with bad workarounds?<br />
And keep me updated, <img src='http://thesmithfam.org/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /><br />
Regards,</p>
<p>Cyril<br />
Ps: this &#8220;workaround&#8221; have a great result with the collidingmices example delivered in the Qt4 distribution, at full screen</p>
]]></content:encoded>
	</item>
</channel>
</rss>
