Adding setViewportUpdateMode(QGraphicsView::FullViewportUpdate); seems to solve it.

@raven-worx I mean drawing part is quite simple, but there is a stuff QGraphicsPathItem doesn't provide, so I had to implement my own class. I will make some experiments with QGraphicsPathItem later, but for now viewportUpdateMode solves an issue.

@Joel-Bodenmann
@raven-worx

They're all good answers :)
Thank you very much :)

@Walux said:

Probably not as good , so i'll use yours .

just for clarification:
Actually this is exactly the same approach, just a step later.
(After the graphics view translated and forwarded it's received events to it's scene).

Yep , fixed !!

Biggest achievement of ma layf.

Topic->setAsSolvedPolicy(Qt::AlwaysTrue);

Thank you for your input!

@raven-worx said:

Are you zooming/scaling in your graphics view?

I can zoom in my graphics view, yes.

@raven-worx said:

It's definitely worth to just extract the visible regions and render them. For this you can subclass QGraphicsPixmapItem's paint() method. In there all the transformations you made on the item itself are already applied to the passed QPainter (see QPainter::transform()).
This approach is tricky and becomes really tricky when you start to rotate the items.

Lucky me, I'm not rotating anything!

I was more thinking about creating smaller QGraphicsPixmapItems and adding them to the scene, but your approach seems cleaner.

ok will do

For the recored, filed QTBUG-53845

Hi,

I may be wrong but based on this, it seems to be an unsupported use case for EGLFS.

@mrjj Yes it seems that...
So now it is solved ;)

Thanks a lot.

@kegon
The thing is as I mentioned you can't rely on their order of appearance (and you shouldn't). For example on my machine I've noticed (sometime ago when debugging) I receive 2 resize events (one with 0, 0 size), then I get the show event and then the paint event. You'd say that (0, 0) resize event is invalid but it's not quite so. If I understand correctly (the Qt source), on X11 (which is what I have) the determination of widget geometry is speculative (so I get seemingly invalid size events) then when everything is set up it works fine. So in conclusion: don't rely on the order of events, only respond to the them!

Kind regards.

@Joel-Bodenmann

There is a quite simple, if ugly solution:

Copy the code of "fitInView" from Qt sources into your class. Give it a new name (e.g. fitInViewTightly) Strip away the modifiers that cause your headache

@Wieland Thank you, I guessed the first was some kind of copy constructor.
As concerns the second, it was just a curiosity of mine. Thank you :)

I know I'm late to the party, but for what it's worth:

There is rarely ever a need to manually update the GraphicsScene. It will automatically update parts whenever you move items (setPos), or change properties of ready-to-use items such as QGraphicsRectItem If you implement your own item and your own paint method, naturally the scene cannot know which properties will affect the paint and which won't. Therefore, you just call update() on the item after you changed any properties that affect the way the item looks If you change the boundingRect(), don't forget to call prepareGeometryChange(), otherwise you will have nasty painting effects Re sorting: qSort, anyone?

Thanks !

After further investigation, it appears that this is because I am using OpenGL - the 'fullUpdate' flag in updateScene is always set in this case - qgraphicsView has "accelerateScrolling = !isGlWidget" [in setupViewport, line 2759] and "fullUpdate = !d->accelerateScrolling" [in updateScene, line 2675]

@alogim
Yes, you can, but then you'll need at some point to update the scene's viewport (the QSceneView) manually and this might have some undesirable effects when you move/resize your widget(s).