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

Thread: QGraphicsScene/QGraphicsView performance problems

  1. #41
    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: QGraphicsScene/QGraphicsView performance problems

    BTW can you explain the composition of a chip with a screen shot ? i think you can simplify the drawing by representing less items which draw sub polygons.
    I mean I could see an array of rectangular items, with some polygons and rect inside.
    The outside rect can be considered as one item.
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  2. #42
    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: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by bnilsson View Post
    You have all of my relevant code in the example. What is missing?
    Knowledge what items represent. I don't want to go through all your code and learn it by trial and error. For example I don't know if you really need 4 points to represent a trapezoid or if those trapezoids have somehow "fixed" properties, for example always a 90deg. angle - then you just need 3 points, or fixed lengths.

    However, the description in Assistant is a bit cryptic, so I will have to test different settings. Will a higher value improve?
    It is nothing you may set. It's a value given by the view to the item's painting routine that tells it how far away the "camera" is from the item. The further, the less details may be seen, so drawing those details becomes obsolete.

    I tend to have the same opinion. But the gv framework is so convenient!
    I don't think it is an overkill. If you design the scene correctly, it will work fine. With a regular widget you'd probably want to have items as well.

    Quote Originally Posted by bnilsson View Post
    Where does the pos() come in?
    It's set to (0,0) by default. The way you do it makes your items very complicated, especially if you'll want later to interact with them somehow. If you have a trapezoid, make it span from (0,0) to the width and height of the trapezoid and them move it into an appropriate position using setPos(). This probably won't yield any performance gain, but will it easier to implement the ShapeItem that doesn't use paths or polygons that are really slow to draw.

    Secondly, can you apply levelofDetail to a high-level draw such as scene->addRect();?
    The rectangle item probably doesn't use LOD, so no. You have to implement your own item for that. It is most essential for your trapezoids. Simplify things wherever possible.

  3. #43
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    4
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QGraphicsScene/QGraphicsView performance problems

    This thought has occurred to me, since the pattern is organized in exposure fields and subfields. So the items could be a FieldItem with child SubFieldsItem, which in turn has child ShapeItems. The ShapeItems are the actual stuff that are drawn by my microchip exposure machine which is using the data file as input, and the fields and subfields are placement parameters.
    Will this item hierarchy in three levels, if implemented, give any performance gain?
    The field content is usually unique for each field, so there is no memory to be gained by repetition. However, if the field and subfield boundaries are to be drawn, these items can be re-used by offset.
    MacOSX user dabbling with Linux and Windows.

  4. #44
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    4
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QGraphicsScene/QGraphicsView performance problems

    Knowledge what items represent. I don't want to go through all your code and learn it by trial and error. For example I don't know if you really need 4 points to represent a trapezoid or if those trapezoids have somehow "fixed" properties, for example always a 90deg. angle - then you just need 3 points, or fixed lengths.
    Ok, now I understand.
    I will have the following kinds of objects to draw:

    FieldBoundary:
    This object is 'virtual', and the drawing of this is optional, to indicate for the viewer how the pattern layout is divided into fields.
    It is always rectangular (special case quadratic), the same size and shape throughout the whole drawing. Typically 800 by 800 micrometer in size. The size is predefined in the file header, and the pattern data comes as position x,y referenced from the upper left corner of the chip.
    SubFieldBoundary:
    This object is 'virtual', and the drawing of this is optional, to indicate for the viewer how the pattern layout in the field is divided into subfields.
    It is always rectangular (special case quadratic), the same size and shape throughout the whole drawing. The subfield size is ALWAYS smaller or equal to the field size, typically 100 by 100 microns in size. The size is predefined in the file header, and the pattern data comes as position x,y referenced from the upper left corner of the current field.
    The Real shapes below are ALWAYS contained and enclosed within one subfield, and thus always smaller.
    XRectangle:
    Should always be drawn. The X side is longer than the Y side. The input data comes as x0,y0,w,h, referenced from the upper left corner of the current subfield.
    YRectangle:
    Should always be drawn. The Y side is longer than the X side. The input data comes as x0,y0,w,h, referenced from the upper left corner of the current subfield.
    XTrapezoid:
    Top and bottom sides parallell. Degenerated into triangles may occur. The input data comes as x0,y0,x1,x2,x3,y3, referenced from the upper left corner of the current subfield.
    YTrapezoid:
    Left and right sides parallell. Degenerated into triangles may occur. The input data comes as x0,y0,y1,y2,x3,y3, referenced from the upper left corner of the current subfield.
    Line:
    Just a line from x0,y0 to x1,y1, referenced from the upper left corner of the current subfield.

    Exposure dose index:
    In the input data file, each Real shape may have a tag to control the exposure dose. Here we us colors (up to 63 colors) to present this.

    Hope this helps.
    MacOSX user dabbling with Linux and Windows.

  5. #45
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    4
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QGraphicsScene/QGraphicsView performance problems

    About LOD:
    t is nothing you may set. It's a value given by the view to the item's painting routine that tells it how far away the "camera" is from the item. The further, the less details may be seen, so drawing those details becomes obsolete.
    So, why discuss it?
    Or is there any way I can make use of it?
    MacOSX user dabbling with Linux and Windows.

  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: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by bnilsson View Post
    About LOD:

    So, why discuss it?
    Or is there any way I can make use of it?
    Ofcourse!
    Snippet from chip demo is below. I have marked some lines with "==" comment.
    See how the chip alters what exactly is drawn when level of detail is so and so.
    When levelOfDetail is less, even though you draw everything, the user won't be able to see the full details of the chip so, why bother to draw everything ?

    Qt Code:
    1. void Chip::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget)
    2. {
    3. Q_UNUSED(widget);
    4.  
    5. QColor fillColor = (option->state & QStyle::State_Selected) ? color.dark(150) : color;
    6. if (option->state & QStyle::State_MouseOver)
    7. fillColor = fillColor.light(125);
    8.  
    9. //============Notice here============
    10. if (option->levelOfDetail < 0.2) {
    11. //===============================
    12. if (option->levelOfDetail < 0.125) {
    13. painter->fillRect(QRectF(0, 0, 110, 70), fillColor);
    14. return; // also notice the return===========
    15. }
    16.  
    17. painter->setPen(QPen(Qt::black, 0));
    18. painter->setBrush(fillColor);
    19. painter->drawRect(13, 13, 97, 57);
    20. return;//========= notice this too
    21. }
    22.  
    23. QPen oldPen = painter->pen();
    24. QPen pen = oldPen;
    25. int width = 0;
    26. if (option->state & QStyle::State_Selected)
    27. width += 2;
    28.  
    29. pen.setWidth(width);
    30. painter->setBrush(QBrush(fillColor.dark(option->state & QStyle::State_Sunken ? 120 : 100)));
    31.  
    32. painter->drawRect(QRect(14, 14, 79, 39));
    33. if (option->levelOfDetail >= 1) {
    34. painter->setPen(QPen(Qt::gray, 1));
    35. painter->drawLine(15, 54, 94, 54);
    36. painter->drawLine(94, 53, 94, 15);
    37. painter->setPen(QPen(Qt::black, 0));
    38. }
    39.  
    40. // Draw text
    41. if (option->levelOfDetail >= 2) {
    42. QFont font("Times", 10);
    43. font.setStyleStrategy(QFont::ForceOutline);
    44. painter->setFont(font);
    45. painter->save();
    46. painter->scale(0.1, 0.1);
    47. painter->drawText(170, 180, QString("Model: VSC-2000 (Very Small Chip) at %1x%2").arg(x).arg(y));
    48. painter->drawText(170, 200, QString("Serial number: DLWR-WEER-123L-ZZ33-SDSJ"));
    49. painter->drawText(170, 220, QString("Manufacturer: Chip Manufacturer"));
    50. painter->restore();
    51. }
    52.  
    53. // Draw lines
    54. QVarLengthArray<QLineF, 36> lines;
    55. if (option->levelOfDetail >= 0.5) {
    56. for (int i = 0; i <= 10; i += (option->levelOfDetail > 0.5 ? 1 : 2)) {
    57. lines.append(QLineF(18 + 7 * i, 13, 18 + 7 * i, 5));
    58. lines.append(QLineF(18 + 7 * i, 54, 18 + 7 * i, 62));
    59. }
    60. for (int i = 0; i <= 6; i += (option->levelOfDetail > 0.5 ? 1 : 2)) {
    61. lines.append(QLineF(5, 18 + i * 5, 13, 18 + i * 5));
    62. lines.append(QLineF(94, 18 + i * 5, 102, 18 + i * 5));
    63. }
    64. }
    65. if (option->levelOfDetail >= 0.4) {
    66. const QLineF lineData[] = {
    67. QLineF(25, 35, 35, 35),
    68. QLineF(35, 30, 35, 40),
    69. QLineF(35, 30, 45, 35),
    70. QLineF(35, 40, 45, 35),
    71. QLineF(45, 30, 45, 40),
    72. QLineF(45, 35, 55, 35)
    73. };
    74. lines.append(lineData, 6);
    75. }
    76. painter->drawLines(lines.data(), lines.size());
    77.  
    78. // Draw red ink
    79. if (stuff.size() > 1) {
    80. painter->setPen(QPen(Qt::red, 1, Qt::SolidLine, Qt::RoundCap, Qt::RoundJoin));
    81. painter->setBrush(Qt::NoBrush);
    82. path.moveTo(stuff.first());
    83. for (int i = 1; i < stuff.size(); ++i)
    84. path.lineTo(stuff.at(i));
    85. painter->drawPath(path);
    86. }
    87. }
    To copy to clipboard, switch view to plain text mode 
    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: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by bnilsson View Post
    Ok, now I understand.
    I will have the following kinds of objects to draw:

    FieldBoundary:
    This object is 'virtual', and the drawing of this is optional, to indicate for the viewer how the pattern layout is divided into fields.
    It is always rectangular (special case quadratic), the same size and shape throughout the whole drawing. Typically 800 by 800 micrometer in size. The size is predefined in the file header, and the pattern data comes as position x,y referenced from the upper left corner of the chip.
    SubFieldBoundary:
    This object is 'virtual', and the drawing of this is optional, to indicate for the viewer how the pattern layout in the field is divided into subfields.
    It is always rectangular (special case quadratic), the same size and shape throughout the whole drawing. The subfield size is ALWAYS smaller or equal to the field size, typically 100 by 100 microns in size. The size is predefined in the file header, and the pattern data comes as position x,y referenced from the upper left corner of the current field.
    The Real shapes below are ALWAYS contained and enclosed within one subfield, and thus always smaller.
    XRectangle:
    Should always be drawn. The X side is longer than the Y side. The input data comes as x0,y0,w,h, referenced from the upper left corner of the current subfield.
    YRectangle:
    Should always be drawn. The Y side is longer than the X side. The input data comes as x0,y0,w,h, referenced from the upper left corner of the current subfield.
    XTrapezoid:
    Top and bottom sides parallell. Degenerated into triangles may occur. The input data comes as x0,y0,x1,x2,x3,y3, referenced from the upper left corner of the current subfield.
    YTrapezoid:
    Left and right sides parallell. Degenerated into triangles may occur. The input data comes as x0,y0,y1,y2,x3,y3, referenced from the upper left corner of the current subfield.
    Line:
    Just a line from x0,y0 to x1,y1, referenced from the upper left corner of the current subfield.

    Exposure dose index:
    In the input data file, each Real shape may have a tag to control the exposure dose. Here we us colors (up to 63 colors) to present this.

    Hope this helps.
    May be you can have only one item to represent the field and its contents and by contents i don't mean child items.

    I am using the terminology "item" to represent an entity on scene and which inherits QGraphicsItem.

    The field item is the item responsible to draw its subfields and contents of subfield.

    Now if levelOfDetail is very less, just draw the outer boundary of field item only.
    If levelOfDetail is less, but not very less, then draw subfield boundary also.
    Only if levelOfDetail is greater enough so that user can see detail, draw all the shapes.
    Again you can finetune more by drawing rect when level of detail is medium and polygon if levelOfDetail is sufficiently large.

    And for the values of levelOfDetail, you have to experiment.

    Edit:
    Chipsize 50000.000 um, 3844 fields, 246016 subfields, 246016 rects, 246016 polys
    Chipsize 100000.000 um, 15625 fields, 1000000 subfields, 1000000 rects, 1000000 polys
    Chipsize 125000.000 um, 24336 fields, 1557504 subfields, 1557504 rects, 1557504 polys
    As you can see considering worst case, you can represent all your data by 24336 field items (instead of 24336 + 1557504 + 1557504 items! ) and chip demo has 50k items!!
    I think your app can be smooth enough if you design it carefully
    All the best
    Last edited by Gopala Krishna; 9th January 2008 at 12:02.
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  8. #48
    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: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by bnilsson View Post
    FieldBoundary:
    This object is 'virtual', and the drawing of this is optional, to indicate for the viewer how the pattern layout is divided into fields.
    It is always rectangular (special case quadratic), the same size and shape throughout the whole drawing. Typically 800 by 800 micrometer in size. The size is predefined in the file header, and the pattern data comes as position x,y referenced from the upper left corner of the chip.
    This is nice. A rectangle which is child of the scene. Coordinates them come relative to the scene.

    SubFieldBoundary:
    This object is 'virtual', and the drawing of this is optional, to indicate for the viewer how the pattern layout in the field is divided into subfields.
    It is always rectangular (special case quadratic), the same size and shape throughout the whole drawing. The subfield size is ALWAYS smaller or equal to the field size, typically 100 by 100 microns in size. The size is predefined in the file header, and the pattern data comes as position x,y referenced from the upper left corner of the current field.
    A rectangle which is child of the field item. The coordinates then come relative to the field.

    XRectangle:
    Should always be drawn. The X side is longer than the Y side. The input data comes as x0,y0,w,h, referenced from the upper left corner of the current subfield.
    Same as above.

    YRectangle:
    Should always be drawn. The Y side is longer than the X side. The input data comes as x0,y0,w,h, referenced from the upper left corner of the current subfield.
    Same here.

    XTrapezoid:
    Top and bottom sides parallell. Degenerated into triangles may occur. The input data comes as x0,y0,x1,x2,x3,y3, referenced from the upper left corner of the current subfield.
    Identified as four points. Child of the subfield. Coordinates relative to the subfield.

    YTrapezoid:
    Left and right sides parallell. Degenerated into triangles may occur. The input data comes as x0,y0,y1,y2,x3,y3, referenced from the upper left corner of the current subfield.
    Same here.

    Line:
    Just a line from x0,y0 to x1,y1, referenced from the upper left corner of the current subfield.
    Child of subfield item.

    To sum things up:
    You need the following items:
    * Field - representing Field and Subfield
    * Rectangle - representing X and Y rectangles
    * Trapezoid - representing X and Y trapezoids
    * Line - representing lines, obviously

    These together will make it easier to manipulate all objects. All coordinates will be relative to their parents thus easier to calculate.

  9. #49
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    4
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QGraphicsScene/QGraphicsView performance problems

    Thanks both of you for two interesting suggestions!
    I am sure I will have more questions shortly!
    MacOSX user dabbling with Linux and Windows.

  10. #50
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    4
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QGraphicsScene/QGraphicsView performance problems

    I have tried to apply the idea of have Fields as the GraphicsItems to be added to the scene, and have the contents of the Field drawn "manually" in the paint method if the GraphicsItem. The result is very promising, I have no apparent memory problems anymore, and when I apply levelOfDetail it is also reasonably fast.
    I store the contents of the field using a QList within the QGraphicsItem Field object. (Is this the best way?)

    A few questions remain for me:
    1) The first draw is always updated twice, maybe even three times. Is there any way to control this?
    2) QGraphicsView keeps track of which Fields to update, whith the knowledge of their bounding boxes and if they are within the field of view. But when zooming in within a Field it is my own responsibility to decide what to draw (inside or outside the view), and for this I need to know the current bounding box of my visible view in the scene context. What methds can I use to get this information?
    3) What is fastest to draw, four QLine-s or a QPolygon?
    MacOSX user dabbling with Linux and Windows.

  11. #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: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by bnilsson View Post
    I store the contents of the field using a QList within the QGraphicsItem Field object. (Is this the best way?)
    It seems to be reasonable but if the size of list remains same after initial insertions probably you can try QVarLengthArray. but you should do it only when you discover memory hiccups.

    Quote Originally Posted by bnilsson View Post
    1) The first draw is always updated twice, maybe even three times. Is there any way to control this?
    May be you can hide the view till loading is going on and once loaded show the view. I am not sure about this.


    Quote Originally Posted by bnilsson View Post
    2) QGraphicsView keeps track of which Fields to update, whith the knowledge of their bounding boxes and if they are within the field of view. But when zooming in within a Field it is my own responsibility to decide what to draw (inside or outside the view), and for this I need to know the current bounding box of my visible view in the scene context. What methds can I use to get this information?
    I guess you can do something like
    Qt Code:
    1. QGraphicsView *v = scene->activeView();
    2. //you can use views() method to get a list of views using the scene
    3. QPointF topLeft = v->mapToScene(v->viewport()->rect().normalized().topLeft());
    4. QPointF botRight = v->mapToScene(v->viewport()->rect().normalized().bottomRight());
    5.  
    6. QRectF visibleRect(topLeft, botRight);
    To copy to clipboard, switch view to plain text mode 
    // This is in terms of scene now

    Quote Originally Posted by bnilsson View Post
    3) What is fastest to draw, four QLine-s or a QPolygon?
    You can try to use QVarLengthArray approach.

    Qt Code:
    1. QVarLengthArray<QLine, 4> array(n);
    2. array.append(QLine(..));
    3. ..
    4.  
    5. painter->drawLines(array.constData());
    To copy to clipboard, switch view to plain text mode 
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  12. #52
    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: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by bnilsson View Post
    I store the contents of the field using a QList within the QGraphicsItem Field object. (Is this the best way?)
    What's wrong with QGraphicsItem::childItems?

    1) The first draw is always updated twice, maybe even three times. Is there any way to control this?
    Hard to say without seeing the code. If you modify the scene after the view is shown for the first time or you use fitInView, then it might happen that the view is drawn twice.

    2) QGraphicsView keeps track of which Fields to update, whith the knowledge of their bounding boxes and if they are within the field of view. But when zooming in within a Field it is my own responsibility to decide what to draw (inside or outside the view),
    Hmm? Why? If you zoom in, the field and its subfields are visible so only they will be drawn. You store subfields as child items of a field, right?

    3) What is fastest to draw, four QLine-s or a QPolygon?
    If you draw the polygon using a painter path then lines are faster. If you draw the polygon and not polyline then definitely lines are faster. But using QPainter::drawPolyLine() will call drawLines() internally, so the overhead is minimal. If you draw lines, use QPainter::drawLines() instead of multiple calls to QPainter::drawLine().

  13. #53
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    4
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QGraphicsScene/QGraphicsView performance problems

    What's wrong with QGraphicsItem::childItems?
    I am not there yet, this will be the next version.
    In the current version, the only QGraphicsitems are the fields, and the content is drawn by painter calls.
    Hard to say without seeing the code. If you modify the scene after the view is shown for the first time or you use fitInView, then it might happen that the view is drawn twice.
    This is what I do. Could you suggest an alternative way, without this effect?
    Hmm? Why? If you zoom in, the field and its subfields are visible so only they will be drawn. You store subfields as child items of a field, right?
    No, not in this version. See above.
    If you draw the polygon using a painter path then lines are faster. If you draw the polygon and not polyline then definitely lines are faster. But using QPainter::drawPolyLine() will call drawLines() internally, so the overhead is minimal. If you draw lines, use QPainter::drawLines() instead of multiple calls to QPainter::drawLine().
    Thanks for this, I will use it.
    Any (performance-wise) preferred way to draw filled surfaces?
    MacOSX user dabbling with Linux and Windows.

  14. #54
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    4
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QGraphicsScene/QGraphicsView performance problems

    I have now made a first attempt to make a parent-child hierarchy implementation.
    I am doing something like this:

    Qt Code:
    1. Field = new QGraphicsRectItem(outRect);
    2. .
    3. .
    4. SubField = new QGraphicsRectItem(outRect, Field);
    5. .
    6. .
    7. XRect = new QGraphicsRectItem(outRect, SubField);
    To copy to clipboard, switch view to plain text mode 
    The result is using a remarkably small amount of memory, but the drawing performance is extremely poor, both compared to the "flat" item strategy. Why?
    Another observation is that I used exactly the same placement calculations as for the "flat" version, and I expected that it all should turn out a mess since the child item should use the origin of its parent, not the global chip origin. Yet it worked the first time, which tell me I don't really understand how this works.
    I will now make QGraphicItem subclasses for the Field, SubField and shape objects to see if it improves performance.
    MacOSX user dabbling with Linux and Windows.

  15. #55
    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: QGraphicsScene/QGraphicsView performance problems

    Wait a second.. What did you try last time ? Did you implement FieldItem which also draws sub fields and internal shapes or did you use Q*Items for the subfields and internal shapes ?

    If you had implemented FieldItem which draws everything inside it, then the performance you got should be better than that having child items. This is because more the items, more there is strain on bsp indexing and hence the whole mechanism slows down.

    @Wysota: Am i wrong with the above assumption as you suggested the child items option ?
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

  16. #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: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by bnilsson View Post
    I am not there yet, this will be the next version.
    In the current version, the only QGraphicsitems are the fields, and the content is drawn by painter calls.
    That's not very efficient.

    This is what I do. Could you suggest an alternative way, without this effect?
    Try changing the order of commands or use a debugger to see why the second redraw is made.

    Any (performance-wise) preferred way to draw filled surfaces?
    Avoid complex shapes. Use levelOfDetail.

    Quote Originally Posted by bnilsson View Post
    I have now made a first attempt to make a parent-child hierarchy implementation.
    I am doing something like this:

    Qt Code:
    1. Field = new QGraphicsRectItem(outRect);
    2. .
    3. .
    4. SubField = new QGraphicsRectItem(outRect, Field);
    5. .
    6. .
    7. XRect = new QGraphicsRectItem(outRect, SubField);
    To copy to clipboard, switch view to plain text mode 
    The result is using a remarkably small amount of memory, but the drawing performance is extremely poor, both compared to the "flat" item strategy. Why?
    Do you mean you pass the same rectangle to the three items? I don't think this is a correct approach. And using custom items you might obtain better speed - use level of detail and modifies shapes and parameters like antialiasing.

    Another observation is that I used exactly the same placement calculations as for the "flat" version, and I expected that it all should turn out a mess since the child item should use the origin of its parent, not the global chip origin. Yet it worked the first time, which tell me I don't really understand how this works.
    Take a closer look at the "dragdroprobot" example - see how the robot is drawn.

    Quote Originally Posted by Gopala Krishna View Post
    @Wysota: Am i wrong with the above assumption as you suggested the child items option ?
    No, you are right.

  17. #57
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    4
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by Gopala Krishna View Post
    Wait a second.. What did you try last time ? Did you implement FieldItem which also draws sub fields and internal shapes or did you use Q*Items for the subfields and internal shapes ?

    If you had implemented FieldItem which draws everything inside it, then the performance you got should be better than that having child items. This is because more the items, more there is strain on bsp indexing and hence the whole mechanism slows down.

    @Wysota: Am i wrong with the above assumption as you suggested the child items option ?
    In the version I referred to (let's call it v1.1) I used the QGraphicsitem subclass FieldItem which draws the field's boundary rectangle, and added it to the scene:
    Qt Code:
    1. class FieldItem : public QGraphicsItem
    2. .
    3. Field = new FieldItem(&outRect,color,&fill);
    4. scene->addItem(Field);
    To copy to clipboard, switch view to plain text mode 
    "color" and "fill" are pointers to the 64-entry colorlist and bool fill parameter.
    Field->paint is responsible for drawing the subfield bounds and the pattern shapes, there are no other GraphicsItems than Fields. The FieldItem object holds a QList with the subfields and pattern shapes, which are added to the Field object by the methods addSubField and addRect:
    Qt Code:
    1. MainWindowImpl::DrawSubFieldBounds() {
    2. .
    3. Field->addSubfield(&sfRect);
    4. .
    5. }
    6. .
    7. MainWindowImpl::DrawRectangle(const QRectF inRectangle) {
    8. .
    9. Field->addRect(&rRect, AreaShot);
    10. .
    11. }
    To copy to clipboard, switch view to plain text mode 
    As a summary, the performance is reasonable at the expense of complexity.

    In the NEXT version (let's call it c1.2) I am using the full parent-child hierarchy with the convenience function QGraphicsRectItem, and ihis is what gives me the poor drawing performance but very light on memory consumprtion.
    I will continue with this by subclassing to Field, SubField, and Shape and include levelOfDetail and as efficient drawing as possible.
    Last edited by bnilsson; 20th January 2008 at 13:13.
    MacOSX user dabbling with Linux and Windows.

  18. #58
    Join Date
    Jan 2008
    Posts
    155
    Thanks
    4
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    MacOS X Unix/X11 Windows

    Default Re: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by wysota View Post
    That's not very efficient.
    It seems you and Gopala Krishna do not agree on this

    Try changing the order of commands or use a debugger to see why the second redraw is made.


    Avoid complex shapes. Use levelOfDetail.
    This would mean I cannot use QGraphicsRectItem, right? I have to make my own subclass?


    Do you mean you pass the same rectangle to the three items? I don't think this is a correct approach.
    Sorry, I was not very clear in this example. (downright confusing!) I use the same name for the Rect, but in different methods. The outRect's are NOT the same.
    And using custom items you might obtain better speed - use level of detail and modifies shapes and parameters like antialiasing.


    Take a closer look at the "dragdroprobot" example - see how the robot is drawn.
    I will.
    MacOSX user dabbling with Linux and Windows.

  19. #59
    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: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by bnilsson View Post
    It seems you and Gopala Krishna do not agree on this
    We do on most things. I agree that more items mean more strain to the indexing, but if you want to decide what to draw and what to skip yourself without any index, it will be much slower. The depth of the index can be changed, so it's only your decision how deep it should be. And as your items don't move, the tree won't have to be rebuilt, so it will be very fast.

    This would mean I cannot use QGraphicsRectItem, right? I have to make my own subclass?
    Right. That's what I'm saying from the very beginning.

  20. #60
    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: QGraphicsScene/QGraphicsView performance problems

    Quote Originally Posted by wysota View Post
    We do on most things. I agree that more items mean more strain to the indexing, but if you want to decide what to draw and what to skip yourself without any index, it will be much slower. The depth of the index can be changed, so it's only your decision how deep it should be. And as your items don't move, the tree won't have to be rebuilt, so it will be very fast.
    If that is the case, then i guess bnilsson can try disabling bsp indexing by using scene->setItemIndexMethod(QGraphicsScene::NoIndex);
    It would also be nice to play around with bspTreeDepth as well if the disabling index doesn't help.
    The biggest difference between time and space is that you can't reuse time.
    -- Merrick Furst

Similar Threads

  1. Performance problems with overlapping qgraphicsitems
    By brjames in forum Qt Programming
    Replies: 13
    Last Post: 4th May 2008, 22:42
  2. Poor performance with Qt 4.3 and Microsoft SQL Server
    By Korgen in forum Qt Programming
    Replies: 2
    Last Post: 23rd November 2007, 11:28
  3. GraphicsView performance problems
    By Gopala Krishna in forum Qt Programming
    Replies: 79
    Last Post: 8th August 2007, 18:32
  4. Replies: 2
    Last Post: 8th March 2007, 23:22
  5. Replies: 1
    Last Post: 4th October 2006, 17:05

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.