QGraphicsScene/QGraphicsView performance problems

[bnilsson]

Here is a stripped down version with no loader and a limited set of redundant functions. I did not want to change the UI part so there are some empty action handling methods, please ignore them.

It draws an area set by "chipsize", divided into fields of size "fieldsize", whuch are in turn divided into subfields of size "subfieldsize", and in each subfield there is one rectangle and one polygon. Chip, field and subfield boundaries are drawn in blue color, while the rectangles and polygons are drawn in black.

Chipsize can range from 50,000 microns up to 125,000 microns, the field size is 800 microns, and subfield size is 100 microns. I kept this sceme to be able to relate to my real needs.

Here, 125,000 micron chipsize is beyond the capacity of any of my machines (1 Mac G5 1GB RAM, and 1 amd64 1GB RAM) while 50,000 micron chipsize can be managed with some patience.
Note that Qt4.3.3 has real problems when zooming in on the amd64, the Qt4.4.0 snapshot is much better. They really must have done something there.

Some logs:
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

[wysota]

Ok, I finally managed to take a look at the app. The example you gave us occupies about 200MB of memory, which is not that bad for 0.5M items ( ~400B per item). The application is horribly slow, but I see some ways to speed it up. I don't know if this will improve the speed significantly, but it's worth to try. I'm going to get rid of your polygon items first.

Edit: Ok, I'm not going to do that, because it'd be quite hard for me as I don't know your code. But I already know the difference should be huge. From what I understand you make each item very big - it's pos() is set to (0,0) and it's rect is defined by the polygon. As you have only four points, there is no point in creating a path from them - you should draw them manualy and return a very tiny bounding rectangle. Furthermore you should make use of the levelOfDetail while painting items - from a big distance you could paint polygons as rects or even just points. It should make a huge difference. And it's not a matter of memory, it's consumption is fine.

[Gopala Krishna]

Ok, I finally managed to take a look at the app. The example you gave us occupies about 200MB of memory, which is not that bad for 0.5M items ( ~400B per item). The application is horribly slow, but I see some ways to speed it up. I don't know if this will improve the speed significantly, but it's worth to try. I'm going to get rid of your polygon items first.

Edit: Ok, I'm not going to do that, because it'd be quite hard for me as I don't know your code. But I already know the difference should be huge. From what I understand you make each item very big - it's pos() is set to (0,0) and it's rect is defined by the polygon. As you have only four points, there is no point in creating a path from them - you should draw them manualy and return a very tiny bounding rectangle. Furthermore you should make use of the levelOfDetail while painting items - from a big distance you could paint polygons as rects or even just points. It should make a huge difference. And it's not a matter of memory, it's consumption is fine.

Very true.. Level of detail really makes lot of difference.. The chip demo which qt provides is really a nice demo on how graphicsview applications can be optimized atleast to some extent.

Actually your app didn't run on my system(1Gb ram, 3GHz, pentium 4 HT) until i changed chip size to 5k.
But to be frank enough, I personally feel gv framework is overkill. Infact your app didn't run(50k) even when i turned of all possible bells and whistles. Also you don't need those unnecessary memory strain as well.
If you are sure that you don't need to select or move items here and there, definitely implementing a widget is best option. Remember you always don't have to draw everything as drawing everything at < .25 scale is hardly visible.

[bnilsson]

First, I want to thank you for your engagement in this. This is my VERY first Qt project, and surely must have missed and misunderstood a lot of things.

Ok, I'm not going to do that, because it'd be quite hard for me as I don't know your code.

You have all of my relevant code in the example. What is missing?

But I already know the difference should be huge. From what I understand you make each item very big - it's pos() is set to (0,0) and it's rect is defined by the polygon.

Here it seems I have missed something really important. I was unaware of pos().

Furthermore you should make use of the levelOfDetail while painting items - from a big distance you could paint polygons as rects or even just points.

Again. I was unaware of levelofDetail, I will study it. However, the description in Assistant is a bit cryptic, so I will have to test different settings. Will a higher value improve?

Gopala:
But to be frank enough, I personally feel gv framework is overkill.

I tend to have the same opinion. But the gv framework is so convenient! But on the other hand, it is the only thing I have looked at so far. Is it as easy to implement scroll and zoom for a regular widget?

pherthyl:
This may be useful to you.

http://labs.trolltech.com/blogs/2008...graphicsitems/

I definitely see this on Linux, but for some reason not on my MacOSX. On Linux, displaying the full chip took time, but was ok finally. Zooming in locked it up completely. On Linux, this was eliminated using Qt4.4.0. Or is this a note of a further improvement?

[bnilsson]

First:

From what I understand you make each item very big - it's pos() is set to (0,0) and it's rect is defined by the polygon.

This statement puzzles me.
I just do

QVector<QPointF> Tpz(4);
<fill in the 4 points>
QPolygonF Trapezoid(Tpz);
scene->addPolygon(Trapezoid,AreaShotPen);

QVector<QPointF> Tpz(4);
<fill in the 4 points>
QPolygonF Trapezoid(Tpz);
scene->addPolygon(Trapezoid,AreaShotPen);

To copy to clipboard, switch view to plain text mode 

Where does the pos() come in?

Secondly, can you apply levelofDetail to a high-level draw such as scene->addRect();?
Or do you have to create a custom QGraphicsItem and apply it to painter->drawRect() to do that?

[Gopala Krishna]

Secondly, can you apply levelofDetail to a high-level draw such as scene->addRect();?
Or do you have to create a custom QGraphicsItem and apply it to painter->drawRect() to do that?

You have to create a custom item. Have a look at the code for demos/chip/chip.cpp for reference.

[Gopala Krishna]

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.

[bnilsson]

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.

[bnilsson]

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.

[bnilsson]

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?

[Gopala Krishna]

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 ?

void Chip::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget)
{
    Q_UNUSED(widget);
 
    QColor fillColor = (option->state & QStyle::State_Selected) ? color.dark(150) : color;
    if (option->state & QStyle::State_MouseOver)
        fillColor = fillColor.light(125);
 
    //============Notice here============
     if (option->levelOfDetail < 0.2) {
    //===============================
        if (option->levelOfDetail < 0.125) {
            painter->fillRect(QRectF(0, 0, 110, 70), fillColor);
            return; // also notice the return===========
        }
 
        painter->setPen(QPen(Qt::black, 0));
        painter->setBrush(fillColor);
        painter->drawRect(13, 13, 97, 57);
        return;//========= notice this too
    }
 
    QPen oldPen = painter->pen();
    QPen pen = oldPen;
    int width = 0;
    if (option->state & QStyle::State_Selected)
        width += 2;
 
    pen.setWidth(width);
    painter->setBrush(QBrush(fillColor.dark(option->state & QStyle::State_Sunken ? 120 : 100)));
 
    painter->drawRect(QRect(14, 14, 79, 39));
    if (option->levelOfDetail >= 1) {
        painter->setPen(QPen(Qt::gray, 1));
        painter->drawLine(15, 54, 94, 54);
        painter->drawLine(94, 53, 94, 15);
        painter->setPen(QPen(Qt::black, 0));
    }
 
    // Draw text
    if (option->levelOfDetail >= 2) {
        QFont font("Times", 10);
        font.setStyleStrategy(QFont::ForceOutline);
        painter->setFont(font);
        painter->save();
        painter->scale(0.1, 0.1);
        painter->drawText(170, 180, QString("Model: VSC-2000 (Very Small Chip) at %1x%2").arg(x).arg(y));
        painter->drawText(170, 200, QString("Serial number: DLWR-WEER-123L-ZZ33-SDSJ"));
        painter->drawText(170, 220, QString("Manufacturer: Chip Manufacturer"));
        painter->restore();
    }
 
    // Draw lines
    QVarLengthArray<QLineF, 36> lines;
    if (option->levelOfDetail >= 0.5) {
        for (int i = 0; i <= 10; i += (option->levelOfDetail > 0.5 ? 1 : 2)) {
            lines.append(QLineF(18 + 7 * i, 13, 18 + 7 * i, 5));
            lines.append(QLineF(18 + 7 * i, 54, 18 + 7 * i, 62));
        }
        for (int i = 0; i <= 6; i += (option->levelOfDetail > 0.5 ? 1 : 2)) {
            lines.append(QLineF(5, 18 + i * 5, 13, 18 + i * 5));
            lines.append(QLineF(94, 18 + i * 5, 102, 18 + i * 5));
        }
    }
    if (option->levelOfDetail >= 0.4) {
        const QLineF lineData[] = {
            QLineF(25, 35, 35, 35),
            QLineF(35, 30, 35, 40),
            QLineF(35, 30, 45, 35),
            QLineF(35, 40, 45, 35),
            QLineF(45, 30, 45, 40),
            QLineF(45, 35, 55, 35)
        };
        lines.append(lineData, 6);
    }
    painter->drawLines(lines.data(), lines.size());
 
    // Draw red ink
    if (stuff.size() > 1) {
        painter->setPen(QPen(Qt::red, 1, Qt::SolidLine, Qt::RoundCap, Qt::RoundJoin));
        painter->setBrush(Qt::NoBrush);
        QPainterPath path;
        path.moveTo(stuff.first());
        for (int i = 1; i < stuff.size(); ++i)
            path.lineTo(stuff.at(i));
        painter->drawPath(path);
    }
}

void Chip::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget)
{
    Q_UNUSED(widget);

    QColor fillColor = (option->state & QStyle::State_Selected) ? color.dark(150) : color;
    if (option->state & QStyle::State_MouseOver)
        fillColor = fillColor.light(125);

    //============Notice here============
     if (option->levelOfDetail < 0.2) {
    //===============================
        if (option->levelOfDetail < 0.125) {
            painter->fillRect(QRectF(0, 0, 110, 70), fillColor);
            return; // also notice the return===========
        }

        painter->setPen(QPen(Qt::black, 0));
        painter->setBrush(fillColor);
        painter->drawRect(13, 13, 97, 57);
        return;//========= notice this too
    }

    QPen oldPen = painter->pen();
    QPen pen = oldPen;
    int width = 0;
    if (option->state & QStyle::State_Selected)
        width += 2;

    pen.setWidth(width);
    painter->setBrush(QBrush(fillColor.dark(option->state & QStyle::State_Sunken ? 120 : 100)));

    painter->drawRect(QRect(14, 14, 79, 39));
    if (option->levelOfDetail >= 1) {
        painter->setPen(QPen(Qt::gray, 1));
        painter->drawLine(15, 54, 94, 54);
        painter->drawLine(94, 53, 94, 15);
        painter->setPen(QPen(Qt::black, 0));
    }

    // Draw text
    if (option->levelOfDetail >= 2) {
        QFont font("Times", 10);
        font.setStyleStrategy(QFont::ForceOutline);
        painter->setFont(font);
        painter->save();
        painter->scale(0.1, 0.1);
        painter->drawText(170, 180, QString("Model: VSC-2000 (Very Small Chip) at %1x%2").arg(x).arg(y));
        painter->drawText(170, 200, QString("Serial number: DLWR-WEER-123L-ZZ33-SDSJ"));
        painter->drawText(170, 220, QString("Manufacturer: Chip Manufacturer"));
        painter->restore();
    }

    // Draw lines
    QVarLengthArray<QLineF, 36> lines;
    if (option->levelOfDetail >= 0.5) {
        for (int i = 0; i <= 10; i += (option->levelOfDetail > 0.5 ? 1 : 2)) {
            lines.append(QLineF(18 + 7 * i, 13, 18 + 7 * i, 5));
            lines.append(QLineF(18 + 7 * i, 54, 18 + 7 * i, 62));
        }
        for (int i = 0; i <= 6; i += (option->levelOfDetail > 0.5 ? 1 : 2)) {
            lines.append(QLineF(5, 18 + i * 5, 13, 18 + i * 5));
            lines.append(QLineF(94, 18 + i * 5, 102, 18 + i * 5));
        }
    }
    if (option->levelOfDetail >= 0.4) {
        const QLineF lineData[] = {
            QLineF(25, 35, 35, 35),
            QLineF(35, 30, 35, 40),
            QLineF(35, 30, 45, 35),
            QLineF(35, 40, 45, 35),
            QLineF(45, 30, 45, 40),
            QLineF(45, 35, 55, 35)
        };
        lines.append(lineData, 6);
    }
    painter->drawLines(lines.data(), lines.size());

    // Draw red ink
    if (stuff.size() > 1) {
        painter->setPen(QPen(Qt::red, 1, Qt::SolidLine, Qt::RoundCap, Qt::RoundJoin));
        painter->setBrush(Qt::NoBrush);
        QPainterPath path;
        path.moveTo(stuff.first());
        for (int i = 1; i < stuff.size(); ++i)
            path.lineTo(stuff.at(i));
        painter->drawPath(path);
    }
}

To copy to clipboard, switch view to plain text mode 

[Gopala Krishna]

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

[wysota]

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.

[bnilsson]

Thanks both of you for two interesting suggestions!
I am sure I will have more questions shortly!

[bnilsson]

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?

[wysota]

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.

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.