QGraphicsScene performing "poorly" on dense scenes
-
@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
