QGraphicsScene performing "poorly" on dense scenes
-
@rkhaotix
Obviously as you realise, the best way to speed things up is to draw less :-). Think about how you can give your items some kind of LOD that kicks in when things get too small on the screen or too complex to see clearly, and when you zoom and drag.
In my experience groups can be rather slow when they have many items and there are many groups in the scene, do you really need groups, maybe just careful parenting might work instead?Hi @kenchan, thanks for your response!
Yes, my main problem is exactly zooming and dragging (mainly!). Since I'm not really experienced in Qt I've been using QGraphicsGroupItem all this time thinking that is the best solution for my application. I did not know that this class can be slow... Can't find such information on the docs. But I'm gonna try a simple item parenting instead of grouping them. It'll be a hard work but I think it can worth a try!
Thanks again!
-
Hi
Check out
http://doc.qt.io/qt-5/qtwidgets-graphicsview-chip-example.html
It used a LOD to get better performance.
LOD means level of detail and its simply a way to reduce what needs to be drawn depending
on the zoom level.
Maybe you can work out something so when fully zoom not all is drawn.This might also give ideas
https://stackoverflow.com/questions/43826317/how-to-optimize-qgraphicsviews-performance -
Hi
Check out
http://doc.qt.io/qt-5/qtwidgets-graphicsview-chip-example.html
It used a LOD to get better performance.
LOD means level of detail and its simply a way to reduce what needs to be drawn depending
on the zoom level.
Maybe you can work out something so when fully zoom not all is drawn.This might also give ideas
https://stackoverflow.com/questions/43826317/how-to-optimize-qgraphicsviews-performanceHi @mrjj ! Yeah, I'll try to apply LOD on my scene.
First I'm refactoring some classes so they can depend less on subitems based on QGraphicSceneItem. I already known the 40000 chips example and I'm studying so I can replicate some of the behaviors there on my application.
Anyway, thanks for the link to StackOverflow that will help me a lot to make some polishments!
-
Hi @mrjj ! Yeah, I'll try to apply LOD on my scene.
First I'm refactoring some classes so they can depend less on subitems based on QGraphicSceneItem. I already known the 40000 chips example and I'm studying so I can replicate some of the behaviors there on my application.
Anyway, thanks for the link to StackOverflow that will help me a lot to make some polishments!
-
-
@rkhaotix
Oh, i almost forgot
Did you already try fiddling with
http://doc.qt.io/qt-5/qgraphicsview.html#cacheMode-prop -
@rkhaotix
Oh, i almost forgot
Did you already try fiddling with
http://doc.qt.io/qt-5/qgraphicsview.html#cacheMode-prop -
@mrjj @kenchan I was wondering... Is there a way to make a highly populated scene to ignore completely items that are not visible and/or have the flag QGraphicsItem::ItemHasNoContents set? If there's a way speed up the rendering by just tweaking these settings I can achieve both results I need: higher rendering speed and allow the user to work in a subset of the database model.
By the way, I tried cache items, reduce the amount of scene objects per database objects and background caching but the result was the same. :(
Didn't tried the LOD yet. -
@mrjj @kenchan I was wondering... Is there a way to make a highly populated scene to ignore completely items that are not visible and/or have the flag QGraphicsItem::ItemHasNoContents set? If there's a way speed up the rendering by just tweaking these settings I can achieve both results I need: higher rendering speed and allow the user to work in a subset of the database model.
By the way, I tried cache items, reduce the amount of scene objects per database objects and background caching but the result was the same. :(
Didn't tried the LOD yet.@rkhaotix Did you try to use minimumRenderSize and :levelOfDetailFromTransform?
Anything too small or outside the viewport should not be painted, however the bounding boxes must be tested so many items may still have a performance hit.
Maybe you could replace the groups with your own containing parent item which contains the children needed to draw the details. If you could draw the details directly in the paint function without using other graphics item, as you would with groups, this might reduce the number of items the engine has to check for boxing when clipping for the viewport? You can also fine tune your LOD for the item when dragging or zooming i.e. just draw the bounding box and not draw the details.Just some ideas for you to consider. Wishing you Good Luck in your efforts.
-
@rkhaotix Did you try to use minimumRenderSize and :levelOfDetailFromTransform?
Anything too small or outside the viewport should not be painted, however the bounding boxes must be tested so many items may still have a performance hit.
Maybe you could replace the groups with your own containing parent item which contains the children needed to draw the details. If you could draw the details directly in the paint function without using other graphics item, as you would with groups, this might reduce the number of items the engine has to check for boxing when clipping for the viewport? You can also fine tune your LOD for the item when dragging or zooming i.e. just draw the bounding box and not draw the details.Just some ideas for you to consider. Wishing you Good Luck in your efforts.
-
I came back here just to thank you! I did some refactoring on some of my classes responsible to represent database models using some of your hints, a the result was the following:
-
I could reduce the amount of scene objects needed to represent a whole database model in ~38%. Putting this in numbers, if we use that huge model above which contains 109630 scene items after the code refactoring the amount of objects is now 67902, an impressive difference of 41728 scene objects! That really makes me happy. I did not make any benchmark but I could notice that the stuttering while moving or zooming diminished sensibly! :)
-
Tried several approaches of LOD but they did not contribute in a relevant way to increase the rendering speed. So I concluded that it could be an unecessary and complex implementation (for some objects) which final result was not as good as I needed.
-
Using less QGraphicsGroupItems was the key for most of the problems. I'm using them now only in important parts where the usage of nested QGraphicsItem could generated an overhead when calculation position of children in certain situations.
-
Fiddling around with all my graphics classes I could determine the main culprit of the performance degradation. The guy in question is the a class based upon QGraphicsGroupItem which represents relationships (the most complex objects in the software). Since these objects carry a considerable number of subitems the scene is having a hard time trying to calculate collisions, do the painting and other operations. So I decided to live with this situation for now... In the right moment I'll improve the class (maybe rewriting it?) so I can squeeze more performance from it.
The important thing now is that the overall speed of rendering operations is better. Since I'm an eternal dissatisfied... Soon or later I'll dive into these important bottlenecks and solve them once of all. For now I'm really glad that solve part of my problem and learned new things about this amazing framework!
Thank you once more, guys!
-
-
I came back here just to thank you! I did some refactoring on some of my classes responsible to represent database models using some of your hints, a the result was the following:
-
I could reduce the amount of scene objects needed to represent a whole database model in ~38%. Putting this in numbers, if we use that huge model above which contains 109630 scene items after the code refactoring the amount of objects is now 67902, an impressive difference of 41728 scene objects! That really makes me happy. I did not make any benchmark but I could notice that the stuttering while moving or zooming diminished sensibly! :)
-
Tried several approaches of LOD but they did not contribute in a relevant way to increase the rendering speed. So I concluded that it could be an unecessary and complex implementation (for some objects) which final result was not as good as I needed.
-
Using less QGraphicsGroupItems was the key for most of the problems. I'm using them now only in important parts where the usage of nested QGraphicsItem could generated an overhead when calculation position of children in certain situations.
-
Fiddling around with all my graphics classes I could determine the main culprit of the performance degradation. The guy in question is the a class based upon QGraphicsGroupItem which represents relationships (the most complex objects in the software). Since these objects carry a considerable number of subitems the scene is having a hard time trying to calculate collisions, do the painting and other operations. So I decided to live with this situation for now... In the right moment I'll improve the class (maybe rewriting it?) so I can squeeze more performance from it.
The important thing now is that the overall speed of rendering operations is better. Since I'm an eternal dissatisfied... Soon or later I'll dive into these important bottlenecks and solve them once of all. For now I'm really glad that solve part of my problem and learned new things about this amazing framework!
Thank you once more, guys!
-
-
I came back here just to thank you! I did some refactoring on some of my classes responsible to represent database models using some of your hints, a the result was the following:
-
I could reduce the amount of scene objects needed to represent a whole database model in ~38%. Putting this in numbers, if we use that huge model above which contains 109630 scene items after the code refactoring the amount of objects is now 67902, an impressive difference of 41728 scene objects! That really makes me happy. I did not make any benchmark but I could notice that the stuttering while moving or zooming diminished sensibly! :)
-
Tried several approaches of LOD but they did not contribute in a relevant way to increase the rendering speed. So I concluded that it could be an unecessary and complex implementation (for some objects) which final result was not as good as I needed.
-
Using less QGraphicsGroupItems was the key for most of the problems. I'm using them now only in important parts where the usage of nested QGraphicsItem could generated an overhead when calculation position of children in certain situations.
-
Fiddling around with all my graphics classes I could determine the main culprit of the performance degradation. The guy in question is the a class based upon QGraphicsGroupItem which represents relationships (the most complex objects in the software). Since these objects carry a considerable number of subitems the scene is having a hard time trying to calculate collisions, do the painting and other operations. So I decided to live with this situation for now... In the right moment I'll improve the class (maybe rewriting it?) so I can squeeze more performance from it.
The important thing now is that the overall speed of rendering operations is better. Since I'm an eternal dissatisfied... Soon or later I'll dive into these important bottlenecks and solve them once of all. For now I'm really glad that solve part of my problem and learned new things about this amazing framework!
Thank you once more, guys!
That is indeed good news.
I have posted a link in
https://forum.qt.io/category/8/showcaseas its a very good example of full blown Qt program,
and maybe the most feature rich Modeler i have seen for PostgreSQL.
Thank you for sharing. -
-
@rkhaotix Great news.
Very pleased to hear you have had some success, thanks for getting back to us with that :-). Really hope you have more success with in it the future. -
That is indeed good news.
I have posted a link in
https://forum.qt.io/category/8/showcaseas its a very good example of full blown Qt program,
and maybe the most feature rich Modeler i have seen for PostgreSQL.
Thank you for sharing. -
@mrjj Wow, thanks for that! I'm working on this project for twelve years and I really want that it can be a reference of database modeler for PostgreSQL ;)
Hi
Well its already famous / recognized :)
https://wiki.postgresql.org/wiki/Design_Tools -
Hi
Well its already famous / recognized :)
https://wiki.postgresql.org/wiki/Design_Tools
