PDA

View Full Version : Qt 5.7 QGraphicsObject paint issue



yagabey
1st August 2016, 12:25
Hi,

I have QGraphicsObject derived items on a QGraphicsScene. Before Qt 5.7 everything was good. But when i compile project with 5.7 , painting of objects are getting out of view as seen on the attached image:
12052

The main widget is split into 2 with a splitter. Left side is my view containing GraphicsObjects and right side is a tableview. As you could see, graphics objects overlaps table view and messes up all painting.

i am just overriding paint method like that:


void RealTimeChartItem::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget)
{
//painter->drawImage(boundingRect(),m_image.toImage());
int width = m_rootData->w;
int height= m_rootData->h;
QRectF mrect= boundingRect().adjusted(width/15,height/10,-width/15,-height/10);

painter->fillRect(boundingRect(),QColor(Qt::white));
painter->fillRect(boundingRect().adjusted(3,3,-3,-3),QColor(m_chrtdata->bgColor));

const QPointF points[7] = {
QPointF(width/8, height/1.3),
QPointF(width/4, height/2) ,
QPointF(3*width/8, height/1.8),
QPointF(width/2, height/2.5),
QPointF(5*width/8, height/2.2) ,
QPointF(3*width/4, height/4),
QPointF(7*width/8, height/3)
};

painter->setPen(QPen(Qt::red));
painter->drawPolyline(points, 7);

painter->setPen(QColor(m_chrtdata->txtColor));

painter->drawLine(mrect.bottomLeft(),mrect.bottomRight());
painter->drawLine(mrect.bottomLeft(),mrect.topLeft());
painter->setPen(QPen(QColor(m_chrtdata->txtColor), 1, Qt::DotLine));
painter->drawRect(mrect);
painter->drawRect(QRectF(mrect.topLeft() ,
QPointF(mrect.bottomLeft().x()+mrect.width()/2,
mrect.bottomRight().y()) ));

painter->drawRect(QRectF(QPointF(mrect.topLeft().x(),
mrect.topLeft().y()+mrect.height()/2) ,
mrect.bottomRight() ));
}


Any idea what changed on qt 5.7 and how to fix this ?

Regards,
Yigit

anda_skoa
1st August 2016, 13:42
Is the black thing is a graphics item and the left part with the dotted background is your graphicsview?

The rendering looks like as if the black thing is a widget that is not part of the splitter but a sibling of the splitter and not in any layout.

Cheers,
_

yagabey
1st August 2016, 14:27
Hi anda_skoa,


Is the black thing is a graphics item and the left part with the dotted background is your graphicsview?


Yes, the dotted part is my view and that view is the left part of splitter. Right part of the splitter is the table view as seen in the screen capture.


The rendering looks like as if the black thing is a widget that is not part of the splitter but a sibling of the splitter and not in any layout.

The black part is painted in the paint method of RealtimeChartItem which is a subclass of QGraphicsObject as shown above. And the objects are inserted into the scene by "scene->addItem(item)" as it should.

Moreover there was nothing wrong with this code until Qt5.7

anda_skoa
1st August 2016, 15:12
Right, I just wanted to understand where each part came from.

This sounds like a bug to me, i.e. the graphicview not clipping as it should.

Can you reproduce that with a simple test program?
Something like a splitter with a QGraphicsView and a label, with a simple line item in the scene, drawn at coordinates that make it reach "outside" the visible area?

Cheers,
_

yagabey
1st August 2016, 23:02
Finally I could create a minimal example . The problem is that:
I have a GraphicsItem which has a QGraphicsProxyWidget as a child. No problem when i add this item into scene

But after adding this item, if i add a regular QGraphicsProxyWidget into scene( in sample code it contains a TableWidget) painting starts to mess up.. When you move the splitter in the example you will see GraphicsItem's paintings on TableWidget on top of each other...!

if you comment that code:

QTableWidget* tableInView = new QTableWidget;
QGraphicsProxyWidget* testProxy = m_scene->addWidget(tableInView);
testProxy->setPos(400,100);

everything starts to work correctly..
By the way this situation only occurs on 5.7...

anda_skoa
2nd August 2016, 00:52
You could check on https://bugreports.qt.io/secure/Dashboard.jspa if that has been reported already or report it if not.

But do you really need some as complex as a table widget inside your graphics scene?

Cheers,
_

yagabey
2nd August 2016, 07:03
Yes i really need it. Moreover, the same error occurs after adding a simple pushbutton like that:


QPushButton* butInView = new QPushButton;
QGraphicsProxyWidget* testProxy = m_scene->addWidget(butInView);
testProxy->setPos(400,100);

This cause QGraphicsItem with a child QGraphicsProxywidget to paint incorrectly.

Added after 22 minutes:

I reported the error:
https://bugreports.qt.io/browse/QTBUG-55070

anda_skoa
2nd August 2016, 09:49
Generally a graphics proxy widget is alway borderline, widgets weren't designed to be rotated, scaled, etc.

That's why such highly dynamic user interfaces that need these kind of transformations are usually built from the ground up, e.g. QtQuick (which in its first version was just QGraphicsItems in a scene).

Cheers,
_

yagabey
2nd August 2016, 11:05
Ok Anda, but there is no rotation or scale on these widgets. I simplified the test code a bit more. Now, there is no complex widgets like table or pushbutton. Only there are two proxywidgets using simple QLabel objects. And the problem still exists.

12054

I realised that when two objects are in the view the one containing child proxy shows that strange paint behaviour. But when the other proxy goes out of view, the painting problem disappears..

anda_skoa
2nd August 2016, 11:51
Yes, sorry, misunderstanding.

I wasn't implying that transformations of some sort would have caused the problem, that seems to originate elsewhere.

What I wanted to say is that widgets were not designed to be in situations graphics items are, e.g. being zoomed or rotated, which is usually the use case for QGraphicsProxyWidget.

Cheers,
_

cordfield
16th August 2016, 10:57
We had a similar bug. Try "setOpacity( 0.999 )" on QGraphicsItem and QGraphicsProxyWidget.

yagabey
16th August 2016, 11:19
Yes, that worked...

schollii
9th September 2016, 15:02
OMG, awesome, thanks for posting a workaround, at least gives us temporary relief and hopefully the Qt folks fix this eventually. Note that for us it was sufficient to set opacity to 1 - 0.00001 on all QGraphicsProxyWidget instances.