Page 3 of 4 FirstFirst 1234 LastLast
Results 41 to 60 of 80

Thread: GraphicsView performance problems

  1. #41
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: GraphicsView performance problems

    Quote Originally Posted by camel View Post
    The problem being of course that the lines look differenty ;-)
    Could you explain what you mean by that? Antialiasing shouldn't have any positive effect on horizontal/vertical lines... You can reduce the contrast by using antialiasing on horizontal/vertical lines, but that doesn't improve the line. You can just change the colour you use for drawing and have the same optical effect...

    By the way... by a "line" I understand a "thin line" not a "thick filled rectangle". Of course you can still have a simmilar effect to antialiasing by using a pen different than a brush...

  2. #42
    Join Date
    Aug 2006
    Location
    Bangalore,India
    Posts
    419
    Thanks
    37
    Thanked 53 Times in 40 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: GraphicsView performance problems

    Quote Originally Posted by wysota View Post
    So the problem is not within drawBackground....
    No, it is. I just said when the problem shows up. The main problem is probably not "within" drawBackground but the method which calls it more often than necessary. I mean though we optimize drawBackground() , we need to find out why it is called many times than necessary. I feel this because of experimenting with larger boundingRect gave good performance - i.e lesser drawBackground calls.

    Quote Originally Posted by wysota View Post
    Yes, you should disable the bsp indexing while moving many items at once and enable it again afterwards. Every time you move an item, the tree may need to be rebuilt. Multiply that by the number of items and number of moves you perform...
    I tried by disabling indexing in mousePressEvent() when selectedItems().isEmpty() == false and enabling it again in release event. This didn't help much either

    Quote Originally Posted by wysota View Post
    If you use zooming, then you are using matrix transformations. You are using them anyway as I'm almost 100% sure viewport-window conversion and/or the transformation matrix is used to obtain local coordinate system for items
    Yeah, i missed this. You are right, but anyway these are unavoidables and are for convenience.
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  3. #43
    Join Date
    Jan 2006
    Posts
    128
    Thanked 28 Times in 27 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: GraphicsView performance problems

    Quote Originally Posted by wysota View Post
    Could you explain what you mean by that? Antialiasing shouldn't have any positive effect on horizontal/vertical lines... You can reduce the contrast by using antialiasing on horizontal/vertical lines, but that doesn't improve the line. You can just change the colour you use for drawing and have the same optical effect...

    By the way... by a "line" I understand a "thin line" not a "thick filled rectangle". Of course you can still have a simmilar effect to antialiasing by using a pen different than a brush...
    I did not say "positive effect", I just said "effect"

    Why the effect:
    A one-pixel line not antialiased is exactly one pixel wide
    A one-pixel line antialiased will have the centre of the line on the border between two pixels. (See here


    If you do not use anti-aliasing for all horizontal and vertical lines (such as the resistors in this example) you will have two very different looking lines.

    You might like the effect of having different lines or not, but they will look different :-)
    Last edited by camel; 17th February 2007 at 18:44. Reason: write it less confusing

  4. #44
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: GraphicsView performance problems

    Quote Originally Posted by Gopala Krishna View Post
    The main problem is probably not "within" drawBackground but the method which calls it more often than necessary.
    That's why I mentioned update(). Try reducing the number of items (for example by simplifying the resistor item to consist of only one item), it may improve performance.

    I mean though we optimize drawBackground() , we need to find out why it is called many times than necessary.
    Funny... I have just taken a look at the profiling info you provided and it seems that it's not mentioned how many time drawBackground() is called. But it might be because of an incorrect compilation of the application (that's why you don't get detailed profiling information for drawBackground()).
    I feel this because of experimenting with larger boundingRect gave good performance - i.e lesser drawBackground calls.
    Increasing boundingRect() causes less modifications of the BSP tree while moving items.

    I tried by disabling indexing in mousePressEvent() when selectedItems().isEmpty() == false and enabling it again in release event. This didn't help much either
    Try disabling it entirely.

    Quote Originally Posted by camel View Post
    I did not say "positive effect", I just said "effect"
    OK

    If you do not use anti-aliasing for all horizontal and vertical lines (such as the resistors in this example) you will have two very different looking lines.
    I didn't say not to antialias the resistors but the grid. You won't notice any differences between lines then as all grid lines will be drawn in the same way and you can manipulate the contrast (as antialiasing blurs the edges of lines to reduce the contrast) by changing the colour of the pen.

  5. #45
    Join Date
    Jan 2006
    Posts
    128
    Thanked 28 Times in 27 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Wink Re: GraphicsView performance problems

    I just wanted to post my last version of the to-be-optimized app.

    Little changes I made, were for example:
    * making sure that it actually paints correctly (also when the view gets to big, and we start to receive negative coordinates ;-)
    * setting QGraphicsScene::NoIndex, with no obvious negative effects
    * noticing that it is actually faster (on X11) to draw the pixmap by hand a few times than to use a brush :-/
    * setting clipping to the exposed rect while painting the nodes

    The top timespenders in the app are basically all related to QRegion, i.e. collision detection and repainting. These can only be optimized...well indirectly...


    Anyways, if anybody would like to try out that version, here it is
    Qt Code:
    1. #include <QtGui>
    2. #include <cmath>
    3.  
    4.  
    5. namespace {
    6. static inline int gridFloor(const qreal& value)
    7. {
    8. if (value < 0) {
    9. return -1 * static_cast<int>(std::ceil(qAbs(value)));
    10. } else {
    11. return static_cast<int>(std::floor(value));
    12. }
    13. }
    14.  
    15. static inline int gridCeil(const qreal &value)
    16. {
    17. if (value < 0) {
    18. return -1 * static_cast<int>(std::floor(qAbs(value)));
    19. } else {
    20. return static_cast<int>(std::ceil(value));
    21. }
    22. }
    23.  
    24. static inline int nextSmallerGrid(const int &value, const int &gridSize)
    25. {
    26. if (value < 0) {
    27. const int absValue = qAbs(value);
    28. return -1 * (absValue + gridSize - (absValue % gridSize));
    29. } else {
    30. return value - (value % gridSize);
    31. }
    32. }
    33. }
    34.  
    35. class GridScene : public QGraphicsScene
    36. {
    37. public:
    38. GridScene(qreal x, qreal y, qreal w, qreal h)
    39. : QGraphicsScene(x, y, w, h)
    40. {
    41. setItemIndexMethod(QGraphicsScene::NoIndex);
    42. }
    43.  
    44. protected:
    45. void drawBackground(QPainter *painter, const QRectF &rect)
    46. {
    47. const int gridSize = 25;
    48.  
    49. if (backgroundCache.isNull()) {
    50. backgroundCache = QPixmap(gridSize, gridSize);
    51. const int middle = gridSize / 2;
    52. {
    53. QPainter backgroundPainter(&backgroundCache);
    54. backgroundPainter.setRenderHints(painter->renderHints());
    55. backgroundPainter.fillRect(QRect(0, 0, gridSize, gridSize), QBrush(Qt::white));
    56. backgroundPainter.setPen(QPen(Qt::darkGreen,0));
    57. backgroundPainter.setBrush(Qt::NoBrush);
    58. backgroundPainter.drawLine(0, middle, gridSize, middle);
    59. backgroundPainter.drawLine(middle, 0, middle, gridSize);
    60. }
    61. }
    62.  
    63. const int realLeft = gridFloor(rect.left());
    64. const int realRight = gridCeil(rect.right());
    65. const int realTop = gridFloor(rect.top());
    66. const int realBottom = gridCeil(rect.bottom());
    67.  
    68.  
    69. const int firstLeftGridLine = nextSmallerGrid(realLeft, gridSize);
    70. const int firstTopGridLine = nextSmallerGrid(realTop, gridSize);
    71.  
    72. QRectF cacheRect(0, 0, gridSize, gridSize);
    73. for (int x = firstLeftGridLine; x < realRight; x += gridSize) {
    74. for (int y = firstTopGridLine; y < realBottom; y += gridSize) {
    75. painter->drawPixmap(QRectF(x, y, gridSize, gridSize),
    76. backgroundCache,
    77. cacheRect);
    78. }
    79. }
    80. }
    81.  
    82. private:
    83. QPixmap backgroundCache;
    84. };
    85.  
    86. namespace {
    87. static inline QPainterPath constructNodeShape(const QRectF& elipseRect)
    88. {
    89. path.addEllipse(elipseRect);
    90. return path;
    91. }
    92. }
    93.  
    94. class Node : public QGraphicsItem
    95. {
    96. public:
    97. Node(QGraphicsItem *par = 0, QGraphicsScene *sc = 0)
    98. : QGraphicsItem(par,sc),
    99. elipseRect(-4.0, -4.0, 8.0, 8.0),
    100. elipsePath(constructNodeShape(QRectF(-3.0, -3.0, 2.0*3.0, 2.0*3.0))),
    101. elipseShape(constructNodeShape(elipseRect)),
    102. nodePen(Qt::darkRed),
    103. nodeBrush(Qt::NoBrush)
    104. {
    105. setFlags(0);
    106. setAcceptedMouseButtons(0);
    107. }
    108.  
    109. void paint(QPainter* p,const QStyleOptionGraphicsItem *o, QWidget *)
    110. {
    111. p->setPen(nodePen);
    112. p->setBrush(nodeBrush);
    113. p->setOpacity(1.0);
    114.  
    115. p->setClipRect(o->exposedRect);
    116. p->drawPath(elipsePath);
    117. }
    118.  
    119. QPainterPath shape() const
    120. {
    121. return elipseShape;
    122. }
    123.  
    124. QRectF boundingRect() const
    125. {
    126. return elipseRect;
    127. }
    128.  
    129. protected:
    130. const QRectF elipseRect;
    131. const QPainterPath elipsePath;
    132. const QPainterPath elipseShape;
    133. const QPen nodePen;
    134. const QBrush nodeBrush;
    135. };
    136.  
    137.  
    138. namespace {
    139. static inline QPainterPath constructResistorPath()
    140. {
    141. QPainterPath resistorPath;
    142. resistorPath.addRect(QRectF(-18.0, -9.0, 36.0, 18.0));
    143. resistorPath.moveTo(-27, 0);
    144. resistorPath.lineTo(-18, 0);
    145. resistorPath.moveTo(18, 0);
    146. resistorPath.lineTo(27, 0);
    147. return resistorPath;
    148. }
    149. }
    150.  
    151. class Resistor : public QGraphicsItem
    152. {
    153. public:
    154. Resistor(QGraphicsItem *par = 0, QGraphicsScene *scene = 0)
    155. : QGraphicsItem(par,scene),
    156. resistorPath(constructResistorPath()),
    157. boundingBox(resistorPath.boundingRect().adjusted(-1, -1, 1, 1)),
    158. resistorSelectedPen(Qt::darkBlue),
    159. resistorOpenPen(Qt::darkGray,1),
    160. resistorBrush(Qt::NoBrush)
    161. {
    162. setFlags(ItemIsMovable | ItemIsSelectable | ItemIsFocusable);
    163. // comment the following 4 lines to see the performance difference
    164. QGraphicsTextItem *t = new QGraphicsTextItem("R1 = 100k",this,scene);
    165. t->setPos(0,-35);
    166. Node * node = new Node(this,scene);
    167. node->setPos(QPointF(-30,0));
    168. node = new Node(this,scene);
    169. node->setPos(QPointF(30,0));
    170. }
    171.  
    172. void paint(QPainter *p, const QStyleOptionGraphicsItem *o, QWidget *)
    173. {
    174. if(!(o->state & QStyle::State_Open))
    175. p->setPen(resistorOpenPen);
    176. if(o->state & QStyle::State_Selected)
    177. p->setPen(resistorSelectedPen);
    178.  
    179. p->setClipRect( o->exposedRect );
    180. p->setBrush(resistorBrush);
    181. p->drawPath(resistorPath);
    182. }
    183.  
    184. QRectF boundingRect() const
    185. {
    186. return boundingBox;
    187. }
    188.  
    189. private:
    190. const QPainterPath resistorPath;
    191. const QRectF boundingBox;
    192. const QPen resistorSelectedPen;
    193. const QPen resistorOpenPen;
    194. const QBrush resistorBrush;
    195. };
    196.  
    197. int main(int argc,char *argv[])
    198. {
    199. QApplication app(argc,argv);
    200. GridScene scene(0,0,1024,768);
    201. for(int j = 2; j < 4; ++j)
    202. for(int i = 1; i <11; ++i)
    203. {
    204. Resistor *r = new Resistor(0,&scene);
    205. r->setPos(j*100, i * 50);
    206. }
    207. QGraphicsView *view = new QGraphicsView(&scene);
    208. view->setRenderHints(QPainter::Antialiasing | QPainter::SmoothPixmapTransform);
    209. view->setDragMode(QGraphicsView::RubberBandDrag);
    210. view->show();
    211. return app.exec();
    212. }
    To copy to clipboard, switch view to plain text mode 


    Uiiii....that was fun... ;-)

  6. #46
    Join Date
    Aug 2006
    Location
    Bangalore,India
    Posts
    419
    Thanks
    37
    Thanked 53 Times in 40 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: GraphicsView performance problems

    Quote Originally Posted by wysota View Post
    That's why I mentioned update(). Try reducing the number of items (for example by simplifying the resistor item to consist of only one item), it may improve performance.
    This won't be possible since I need node to be independent of component.

    Quote Originally Posted by wysota View Post
    Funny... I have just taken a look at the profiling info you provided and it seems that it's not mentioned how many time drawBackground() is called. But it might be because of an incorrect compilation of the application (that's why you don't get detailed profiling information for drawBackground()).
    I'll post the proper one after recompilation today.

    Quote Originally Posted by wysota View Post
    Increasing boundingRect() causes less modifications of the BSP tree while moving items. Try disabling it entirely.
    Could the last post in this thread mean an improvement of performance in Qt4.3 with indexing enabled.
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  7. #47
    Join Date
    Aug 2006
    Location
    Bangalore,India
    Posts
    419
    Thanks
    37
    Thanked 53 Times in 40 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: GraphicsView performance problems

    Quote Originally Posted by camel View Post
    I just wanted to post my last version of the to-be-optimized app.

    Little changes I made, were for example:
    * making sure that it actually paints correctly (also when the view gets to big, and we start to receive negative coordinates ;-)
    * setting QGraphicsScene::NoIndex, with no obvious negative effects
    * noticing that it is actually faster (on X11) to draw the pixmap by hand a few times than to use a brush :-/
    * setting clipping to the exposed rect while painting the nodes

    The top timespenders in the app are basically all related to QRegion, i.e. collision detection and repainting. These can only be optimized...well indirectly...


    Anyways, if anybody would like to try out that version, here it is
    Qt Code:
    1. #include <QtGui>
    2. #include <cmath>
    3.  
    4. ....
    To copy to clipboard, switch view to plain text mode 


    Uiiii....that was fun... ;-)
    Thanks for the cleaner optimized version.
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  8. #48
    Join Date
    Aug 2006
    Location
    Bangalore,India
    Posts
    419
    Thanks
    37
    Thanked 53 Times in 40 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: GraphicsView performance problems

    Just to fine tune my understanding. Is the indexing helpful only if we use QGraphicsScene::items() in our code? Doesn't the framework use this internally (while detecting event receiving item)thereby reducing speed?
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  9. #49
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: GraphicsView performance problems

    Quote Originally Posted by Gopala Krishna View Post
    This won't be possible since I need node to be independent of component.
    As far as I remember you had an additional item for displaying some text which you can easily get rid of. But I may be wrong, maybe it was someone else with such an architecture.

    I'll post the proper one after recompilation today.
    I meant that the compilation was not correct, not the method.

    Could the last post in this thread mean an improvement of performance in Qt4.3 with indexing enabled.
    Yes. Andreas describes the exact solution you should use.

    Quote Originally Posted by Gopala Krishna View Post
    Just to fine tune my understanding. Is the indexing helpful only if we use QGraphicsScene::items() in our code? Doesn't the framework use this internally (while detecting event receiving item)thereby reducing speed?
    It is helpfull for answering a question "What parts of the canvas does a particular item occupy?" which is strongly related to "What items collide with point X?". So it is for example used to swiftly determine which item was clicked.

  10. #50
    Join Date
    Jan 2006
    Posts
    128
    Thanked 28 Times in 27 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: GraphicsView performance problems

    Quote Originally Posted by Gopala Krishna View Post
    Just to fine tune my understanding. Is the indexing helpful only if we use QGraphicsScene::items() in our code? Doesn't the framework use this internally (while detecting event receiving item)thereby reducing speed?
    Yes the framework uses it internally, but it is a tradeoff (as so much in life ;-)

    When you use the Index, the collision-detection may be sped up, but every position/size change of every item will cost you.
    If you do not use the index, finding an item at a certain location will probably be linear to the number of items in the scene, but you can move/change very cheaply.

    If you have many moving things but not so many overall, turning of the index may be a good idea.
    If you have many mostly stationary items, the index is very nice indeed.

    In the end it depends on experimentation (or very carefull analysis ;-) to find the optimal solution for you.


    Since you were keen on moving many items at the same time, it is disabled here. ;-)

    I think one could think about it like this (for n: all items, x:moving items)
    Looking up items in the index costs log(n)but returns a filtered selection of items z with n >= z >= x
    When you have a repaint, you need to find the repainted items, check if they are really included in the repainted area and then repaint them (which we ignore since it does not change with the use of the index ;-), which will cost about O(log(n) + z). Since you are moving you also need to update the index which cost O(log(n)) which means updating for all items costs O(log(n) * x). If we say that painting and updating is done in lockstep, each this step will cost O(x*log(n) + z). (let us hope that the index is sufficiently well thought out so that z is always very near to x and just say the cost is O(x*log(n)))

    If you do not use the index, you have to check each item if it is included, then repaint , ie it will cost O(n). When we are moving we do not need to update anything, thus the total cost will be somewhere around O(n)

    Now we have the choice O(n) or O(x*log(n)) which is better?
    Depends on your purposes, if you have the need to move/change nearly as many items as there are in the scene, the non index version with O(n) is better than the index version with O(n*log(n)).
    If the number of changing/moving items is much smaller than the total items, ie n >> x, the index version is clearly better O(log(n) * small number) vs. O(n)



    So that concludes my lecture on the run time behavior of the graphics scene. Next week: Mating Rituals of the Norwegian Widget.

    [By the way, since half of the time I do not know what I talk about take everything here with a grain of salt ;-) ]

    EDIT:
    Actually there is another factor in there: The checks for the repaints is done per "dirty" area d, which should (for moving items) be d < 2*x. Why ? The dirty areas may be combined if they are overlapping but you have always one for where the object was, and one for where the object is.

    So in the end it would realy be:
    O(log(n) * x * d) vs. O(n * d)
    This explains for example why it was faster for you when you increased the bounding rect of the resistors. By increasing the bounding rect you created overlapping regions and thus less work had to be done.
    Worst case: O(log(n) * n) when overlapping vs. O(log(n) * n^2) when not.

    EDIT 2:
    As Andreas explains in the post you mentioned, the index will be changed in 4.3 so this analysis is not valid for Qt > 4.2
    Last edited by camel; 18th February 2007 at 13:10.

  11. The following user says thank you to camel for this useful post:

    Gopala Krishna (18th February 2007)

  12. #51
    Join Date
    Aug 2006
    Location
    Bangalore,India
    Posts
    419
    Thanks
    37
    Thanked 53 Times in 40 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: GraphicsView performance problems

    Quote Originally Posted by camel View Post
    Yes the framework uses it internally, but it is a tradeoff (as so much in life ;-)

    When you use the Index, the collision-detection may be sped up, but every position/size change of every item will cost you.
    If you do not use the index, finding an item at a certain location will probably be linear to the number of items in the scene, but you can move/change very cheaply.
    ....
    ..
    Thanks a lot camel! I am really grateful to you for explaining these details. They are really worth a lot for me
    But one thing regarding my app, you cant say whether you will use many items, move them all together since that is all dependent on user. So I'd be happy if the performance is better for moving around 10-15 components at a time on medium end computers. Also I feel that maximum components generally used will be around 30.
    But since I need to provide proper feedback while drawing wires, I optimized there to use QRubberBand's while the wires are being resized or drawn, which was rather huge performance improvement.

    Just one more question here. Suppose I want to show feedback of possible connections while moving components (say the nodes of component overlap with the node of other component) by drawing those nodes with different color or some other way, I may need good and fast collision detection - which means I might need indexing. Rather than compromising for trade off of using this, if I decide to show feedback only if mouse rests for a few milliseconds by using timers, will I need indexing ?
    Last edited by Gopala Krishna; 18th February 2007 at 13:27. Reason: updated contents
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  13. #52
    Join Date
    Jan 2006
    Posts
    128
    Thanked 28 Times in 27 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: GraphicsView performance problems

    Quote Originally Posted by Gopala Krishna View Post
    Thanks a lot camel! I am really grateful to you for explaining these details. They are really worth a lot for me
    You are welcome. Actually it is a good and fun way for me to avoid that what I should be doing in the moment ;-)


    Quote Originally Posted by Gopala Krishna View Post
    Just one more question here. Suppose I want to show feedback of possible connections while moving components (say the nodes of component overlap with the node of other component) by drawing those nodes with different color or some other way, I may need good and fast collision detection - which means I might need indexing.
    Best thing: Benchmark ;-)
    Check if the lookup is reasonable fast on 4.2 without the index, and check if the moving is reasonable fast on 4.3 (try the snapshots)
    then use
    Qt Code:
    1. #if QT_VERSION <= 0x040300
    2. setItemIndexMethod(QGraphicsScene::NoIndex);
    3. #endif
    To copy to clipboard, switch view to plain text mode 
    to only switch of the index for 4.2

    Quote Originally Posted by Gopala Krishna View Post
    Rather than compromising for trade off of using this, if I decide to show feedback only if mouse rests for a few milliseconds by using timers, will I need indexing ?
    It is probably a smart thing to do. Restarting a timer and storing the last location to a variable is probably faster than to do a collision detection on every mouse move. If you keep the interval short enough people will probably not even notice ;-)
    Even then indexing is helpfull as it would speed it up, but you will not take as much as an performance hit without it as you would if you just went ahead and did collision detection all the time.


    Again, probably best advice: "See What Works"(tm)
    And: Keep KCacheGrind handy ;-)

  14. #53
    Join Date
    Aug 2006
    Location
    Bangalore,India
    Posts
    419
    Thanks
    37
    Thanked 53 Times in 40 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: GraphicsView performance problems

    Quote Originally Posted by wysota View Post
    I meant that the compilation was not correct, not the method.
    Ah how fortunate I am. I didn't recompile Qt because of power failure. BTW, I tried to analyze more from kcachegrind itself. Unfortunately I can't post the generated file(even after bzip2 --best) due to size limit of attachments. The following are first few functions of QGraphicsView:: paintEvent()

    [HTML] Ir Count Calee
    --------------------------------------------------------------------------
    14.97 2578 QPainter::setClipRect()
    14.12 1289 QGraphicsScene::items(QRectF const&)
    9.29 21 QGraphicsView::drawItems()
    2.3 2578 QPainter::restore()
    2.06 78,272 QRectF:: operator|
    0.99 1289 QGraphicsView::drawBackground()[/HTML]


    NOTE: indexing is disabled for this profile and grids drawn as camel did in his last code.
    Also HTML instead of QUOTE tag is for clarity.

    This means QRectF:: operator | is proving costly in this case!!
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  15. #54
    Join Date
    Jan 2007
    Location
    UKRAINE
    Posts
    4
    Qt products
    Qt4
    Platforms
    Unix/X11

    Exclamation Re: GraphicsView performance problems

    I have idea. What changed when I createItemGroup with selected object then move this group by mouse, then destroyItemGroup (when finish moving). Can I increase performance?

  16. #55
    Join Date
    Oct 2006
    Location
    New Delhi, India
    Posts
    2,467
    Thanks
    8
    Thanked 334 Times in 317 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: GraphicsView performance problems

    phew !!
    what a thread ... nice to know so many things about improving performance...

    Gopal, u made a small mistake, and i wonder why it wasnt caught...u were drawing out of the boundingrect !!
    Problem was not with drawing backgound... ur items as slow as without drawing the background

    just replace ur first code ... change ur boundingRect to
    Qt Code:
    1. QRectF boundingRect() const
    2.  
    3. {
    4.  
    5. qreal pw = 0.5;
    6.  
    7. QRectF rectf = QRectF(-36,-9,70,18); // use this rectangle
    8. //QRectF rectf = QRectF(-27,-9,54,18);
    9. return rectf.adjusted(-pw,-pw,pw,pw);
    10.  
    11. }
    To copy to clipboard, switch view to plain text mode 


    see the performance difference urself... !!!
    have to go thru other posts... will see them when have time... and if I can improve more,,, will surely let u know
    Last edited by aamer4yu; 20th February 2007 at 11:57.

  17. #56
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: GraphicsView performance problems

    Quote Originally Posted by Kuzemko View Post
    I have idea. What changed when I createItemGroup with selected object then move this group by mouse, then destroyItemGroup (when finish moving). Can I increase performance?
    No, those will still be distinct items which might occupy different nodes in the BSP tree.

  18. #57
    Join Date
    Jan 2006
    Posts
    128
    Thanked 28 Times in 27 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: GraphicsView performance problems

    Quote Originally Posted by aamer4yu View Post
    Gopal, u made a small mistake, and i wonder why it wasnt caught...u were drawing out of the boundingrect !!
    No actually he was not. The bounding rect you created was much too large. You only have to specify the bounding rect of the current item. You seem to want to include additionally the bounding rects of the child items.

    Quote Originally Posted by aamer4yu View Post
    see the performance difference urself... !!!
    The reson for the perfomance advantage in this case can be seen in my analysis a few posts up.

  19. #58
    Join Date
    Aug 2006
    Location
    Bangalore,India
    Posts
    419
    Thanks
    37
    Thanked 53 Times in 40 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: GraphicsView performance problems

    Has anyone tried the above codes with the snapshots(Qt4.3) ? If so did anybody notice performance difference ? This will surely improve my confidence since my project will mostly be released during that the release of Qt4.3
    Last edited by Gopala Krishna; 20th February 2007 at 14:14. Reason: updated contents
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  20. #59
    Join Date
    Aug 2006
    Location
    Bangalore,India
    Posts
    419
    Thanks
    37
    Thanked 53 Times in 40 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: GraphicsView performance problems

    Do you think its better to fake bounding rect for now (larger bounding rect for all components) to address performance issue ?
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  21. #60
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: GraphicsView performance problems

    Quote Originally Posted by Gopala Krishna View Post
    Do you think its better to fake bounding rect for now (larger bounding rect for all components) to address performance issue ?
    Increasing the boundingRect will cause a performance drop when the number of items increases as more and more items will have to be redrawn when you do anything because of overlapping boundingRects.

Similar Threads

  1. Performance problems with overlapping qgraphicsitems
    By brjames in forum Qt Programming
    Replies: 13
    Last Post: 4th May 2008, 22:42
  2. QT GraphicsView Help
    By mistertoony in forum Qt Programming
    Replies: 15
    Last Post: 15th February 2007, 05:17
  3. Replies: 1
    Last Post: 4th October 2006, 17:05
  4. QT4 Plugins - problems, problems
    By NormanDunbar in forum Qt Programming
    Replies: 6
    Last Post: 9th May 2006, 16:39
  5. Increasing performance from Qtextedit, listview, etc?
    By taylor34 in forum Qt Programming
    Replies: 1
    Last Post: 16th February 2006, 11:20

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.