Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QGraphicsView\QGraphicsItem render issues, help to optimize
I have a custom QGraphicsView and a custom QGraphicsItem (which paint a rectangle inside rectangle - nothing fancy), the custom QGraphicsView show a maze built from the custom QGraphicsItem's.
When hovering with the mouse over an item a details about this item are shown in a dockwidget on the side, also I have a zoom in/out slider. All features working fine and fast with mazes of 8x8 to 256x256, but when trying mazes with larger sizes (like 512x512, 1024x1024), the zoom out is working slow (I notice that if I zoom in everything work fast), the details shown when hovering with the mouse are display with a little delay, and when zooming out and just hover with the mouse fast over few items some small artifacts appears on the items (they disappear when I zoom in or minimize the window and then maximize it).
For now I'm not using any optimization flags, I have read about them and try some of them but haven't saw any changes of the above behavior.
What I have try so far on my QGraphicsView:
I'm looking for ideas on how to optimize my QGraphicsView\QGraphicsItem to handle large amount of items.
Did you try to use profiler to find out bottle necks of your application?
I can't run profiler: error -->"Could not connect to the in-process QML profiler..."
- QML checkbox is set next to the debugger
I didn't mean QML profiler. I meant using of something like "grof":http://www.richelbilderbeek.nl/CppQtGprofExample1.htm. You may also look "here":http://qt-project.org/wiki/Profiling-and-Memory-Checking-Tools to find out other tools.
aha Ok thanks.
- grof link don't works for me :S, maybe you have another link for it?
Try to look at "here":http://www.qtcentre.org/wiki/index.php?title=Profiling_with_GNU_gprof and "here":http://habrahabr.ru/post/147109/ (in Russian). Of cause you may use any profiling tool. The main idea is to find out, how does each option set affect application performance. However, if you don't see the difference without using profiling tools, then there might not be real difference, cause it's (graphics rendering) not bottleneck
peruserkki last edited by
We had similar problem when developing "TimeToPic":http://www.timetopic.net performance analyzer. Adding thousands of elements into graphicsscene resulted slow operation. This happened in our case when zooming out.
We implement workaround by using 2 scenes. One for items that are visible and one that are not (but need to be stand by when becoming visible again.)
We also found that 1) memory allocation and 2) adding items to scene takes time. One way to speed up this is to turn index method off. Then adding items seems to be faster. The tradeoff is longer lookup.
After all it seems to be depending amount of elements you have in your scene.
Could you tell how many items you have in your scenes and have you memory allocation (for windows use Process explorer for example)?
Also, if you have some items with unusual shape (i.e. with shape() method overriden) than you may decrease number of memory reallocations by replacing code like:
shape << point_1 << point_2...;
shape << point_1 << point_2...
or something like this. This may also increase performance.
We are building a Maze which constructed from custom rectangle like shapes (each shape is a rectangle inside rectangle), mazes size are 8x8,16x16...4096x4096 (maze sizes are also the amount of items on the screen). For now 4096x4096 takes too much memory (around 12GB), but 2048x2048 takes only around 1.8GB.
peruserkki last edited by
I read your original post again.
I understand that your application creates maze elements once. It is possible to zoom and unzoom maze and slow down happens when elements count 515^2 makes view slow.
I assume that 'maze element' size is creater than 1x1 pixels?
Few things comes to my mind:
You told that 2048x2048 takes 1.8GB RAM. How about good situation 256x256 when things seems to be ok? >> If computer starts swapping memory, it will cause some slowdown at least.
What is your viewport update method (this may impact also your small artifact problem)?
How do calculate your bounding rect in your custom QGraphicsItem?
Are you using clippings etc in yor custom QGraphicsItem paintEvent?
Check this "blog post":http://thesmithfam.org/blog/2007/02/03/qt-improving-qgraphicsview-performance/