QGraphicsScene performing "poorly" on dense scenes
-
wrote on 29 Oct 2018, 23:38 last edited by rkhaotix
Hey guys! :)
I'm scratching my head trying to figure out how to improve the performance of the software. The pictures below are from database models that my project is capable of create (https://pgmodeler.io). Well, I've been learning Qt myself for a decade and I'm pretty sure that I'm missing something that can help me to improve the rendering speed of the scene on my app.
First let me describe how pgModeler handles the database objects. Say we have a table with 10 columns (without contraints). Graphically, this table is constructed using other 40 QGraphicsItem based objects (polygons, rectangles, ellipses, lines, text boxes, etc) grouped in a QGraphicsGroupItem. All them rendered over a generated pixmap which simulates a grid.
The scene rendering works pretty well when I have a relatively small/medium database model (say 200 tables and 200 relationships). For instance, the first picture below contains ~26 database objects which produce ~1050 scene objects, that's almost 40 scene objects per database object. I see that this is one of the bottlenecks on my application... Graphical objects are extremely "bloated". I can easely reduce those object instanciation by 20% or a bit more but still resulting in lots of scene elements.
Now, a more aggressive example, the database model below contains ~1670 database objects which produce ~109630 scene objects. This is where the scene preformance is heavily degradated. It's almost impossible to move two selected tables over the canvas. What intrigues me is that when moving a single object the performance is quite acceptable.
Said that, here's my question: what tricks do you recommend me so I can get a better performance? On my side, I'm planning the following:
-
Try to reduce as much as possible the amount of scene objects used to represent a single database object;
-
Create a some kind of workspaces where not all objects are rendered at once where the user can choose which set of database objects to work. This is an old request and I'm pretty motivated to follow this path in order to get more speed on the rendering operations.
Thanks in advance!
Greetings from Brazil!
P.S.: Please, forgive the poor English! :o) -
-
Hey guys! :)
I'm scratching my head trying to figure out how to improve the performance of the software. The pictures below are from database models that my project is capable of create (https://pgmodeler.io). Well, I've been learning Qt myself for a decade and I'm pretty sure that I'm missing something that can help me to improve the rendering speed of the scene on my app.
First let me describe how pgModeler handles the database objects. Say we have a table with 10 columns (without contraints). Graphically, this table is constructed using other 40 QGraphicsItem based objects (polygons, rectangles, ellipses, lines, text boxes, etc) grouped in a QGraphicsGroupItem. All them rendered over a generated pixmap which simulates a grid.
The scene rendering works pretty well when I have a relatively small/medium database model (say 200 tables and 200 relationships). For instance, the first picture below contains ~26 database objects which produce ~1050 scene objects, that's almost 40 scene objects per database object. I see that this is one of the bottlenecks on my application... Graphical objects are extremely "bloated". I can easely reduce those object instanciation by 20% or a bit more but still resulting in lots of scene elements.
Now, a more aggressive example, the database model below contains ~1670 database objects which produce ~109630 scene objects. This is where the scene preformance is heavily degradated. It's almost impossible to move two selected tables over the canvas. What intrigues me is that when moving a single object the performance is quite acceptable.
Said that, here's my question: what tricks do you recommend me so I can get a better performance? On my side, I'm planning the following:
-
Try to reduce as much as possible the amount of scene objects used to represent a single database object;
-
Create a some kind of workspaces where not all objects are rendered at once where the user can choose which set of database objects to work. This is an old request and I'm pretty motivated to follow this path in order to get more speed on the rendering operations.
Thanks in advance!
Greetings from Brazil!
P.S.: Please, forgive the poor English! :o)wrote on 30 Oct 2018, 01:20 last edited by@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? -
-
@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?wrote on 30 Oct 2018, 14:08 last edited byHi @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-performancewrote on 30 Oct 2018, 19:06 last edited byHi @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 -
wrote on 30 Oct 2018, 23:20 last edited by rkhaotix
@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.wrote on 30 Oct 2018, 23:48 last edited by@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.
-
wrote on 2 Nov 2018, 02:03 last edited by
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
1/20