Qt and Linux - QGraphicsItems with low performance

Question

Qt and Linux - QGraphicsItems with low performance

Navigation

#1 by (1 votes)

1

I'm having performance problems with the painting in Qt and the QGraphicsItems in Linux. It gets very "locked" when I add things to the painted (grillas and others). I put a qDebug in the paint to see which area is drawing:

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

    qpenOld = painter->pen();

    painter->setClipRect(item->exposedRect);
    painter->setClipping(true);
    qDebug() << item->exposedRect;

    for(int x = 0; x < polys.count(); x++)
    {
        PolyTrack pl = polys.at(x);
        painter->setPen(penRect);
        painter->drawPolygon(pl.p);
        painter->setPen(penLines);
        painter->drawLine(pl.l);
    }
    painter->setPen(qpenOld);
}

And the output of qDebug is always the same, being that I zoom and scale the view. Is what I'm doing right? On the other hand, define variables in the paint , also is reason for the performance to be bad ?. If the definition of variables in paint is inevitable, it is advisable that they be pointers (are they faster)? Thank you for clarifying these doubts, given that the system is in real time and I need you to paint more fluently.

c++ rendimiento qt

asked by Emiliano Torres 13.06.2018 в 14:41

source

1 answer

how to add data to a Listview? Differences between FETCH ABSOLUTE and FETCH RELATIVE

score 1 · Answer 1

Performance problems can come in several ways:

Bounding boxes : You have not indicated how you calculate the size of QGraphicsItem . If the size is excessive, repaint events will be launched more often and they will involve more pixels ... done accounts. As long as the cost is not totally exclusive it is preferable to reduce the bounding box to the minimum necessary.

Using cliping : You're already applying ... so this part saves me. The only thing that the call to setClipping is redundant and unnecessary.

Antialiasing: It is worthwhile that the graphics are cooler ... but this layer of processing has a cost that can be excessive. As with the first point, you do not indicate anything about it, so I do not know if you are applying it or not.

Do not ask about the size of the vector in each iteration. Although the vectors can be quite optimized ... it does not have to be that way. If in each iteration you have to ask about the size of the vector you are wasting some cycles that can be precious:

for( int x=0, max=polys.count(); x<max; x++ )

Do not make unnecessary copies. In each iteration of the loop you are creating a copy of an object of type PolyTrack and this is something not only unnecessary but also counterproductive. Consider using references (constants to be able to be):

PolyTrack const& pl = polys.at(x);

By combining the last two points, if you use C ++ 11 or higher, consider using the for based on ranges:

for( PolyTrack const& pl : polys )

Do not use Q_UNUSED . This macro is intended, mainly, to avoid warnings when using RAII . If you are not going to use a parameter of the function, it is preferable to comment on the parameter itself. With this you can get a release of the processor and reduce the need to pull the battery (slower):

void TrackFarmGraph::paint(QPainter *painter, const QStyleOptionGraphicsItem *item, QWidget * /*widget*/)

That said:

Is what I'm doing right?

Scaling is something that performs the next level. It is alien to QGraphicsItem , then he must always give the same coordinates.

On the other hand, defining variables in paint , is it also a reason for poor performance?

Depends ... If you end up using records to manage those variables and their construction is free (as with native types) ... performance is not going to be penalized.

If it is inevitable to define variables in paint , is it convenient that they are pointers (are they faster)?

That the pointers are faster than the variables is a lie, at least if it is taken as a canonical response.

Of course it's faster to copy a pointer than a heavy object:

struct POO
{
  int array[100];
};

POO var1, var2, *ptr1, *ptr2;
POO var2 = var1; // Se copia el array -> pesado
ptr1 = ptr2;     // Se copian direcciones de memoria -> ligero

But the times are the same when working with smaller types:

int var1, var2;
int *ptr1, *ptr2;

// Ambas operaciones consumen los mismos ciclos de reloj
var1 = var2;
ptr1 = ptr2;

And, on the other hand, the pointers add an indirection that must be resolved every time that you want to access information about the object you have targeted. In other words, the pointers penalize access to the object:

POO objeto;
POO* ptr;

objeto.funcion(); // Llamada directa -> más rápido
ptr->funcion(); // Añade indirección -> más lento

A possible exception to this case would be the virtual functions ... but I do not think that it is an issue that will be applied in your case.