-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
little improvements in composer module #33
Conversation
Maybe someone have any question about changes? |
{ | ||
mComposition->addItemToZList( this ); | ||
} | ||
init(manageZValue); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason to extract all the stuff from the constructor out into a init method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, because we use init in 2 constructor, thereby remove duplication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh I see now, makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
glad to hear it
I am quite curious about the optimization you have done in composer / map canvas. Can you comment somehow the performance with/without using OpenGL widget, e.g. measure the time required for rendering? Because using OpenGL does not automatically mean that something will be faster - only certain usage patterns result in faster and therefore I would like to see a proof that these optimizations make sense. Also not everyone has the hardware acceleration working, so it might be interesting also to see the performance with software emulation. |
I apologize for the rant. I mean optimization in QgsComposerItem where i delete unnecessary deletion and creation of QGraphicsItem. About OpenGL, right now I work on project where we have a lot of items over the mapCanvas, they all can move and resize (changes occur immediately <<- in this moment we lose in productivity), so when we have count of items about 200 we observed no long delays with software emulation. Then I use OpenGl and count of items when we have dalys is about 4 000, all is fine moving them or resizing are very fast. Therefore I thought it would be nice to see such results in Composer Module of QGis, because in this module user can change items and can have many items. |
Hi Rokemoon Just back from the weekend. I'm going to review the changes during the next days. Regards, |
Hello mhugent. |
Hi Rokemoon I also think we should stay with the default paint engine. It is a very rare case to have several hundreds of items in a composer layout. With a new paint engine, there is the possibility to have new problems (e.g. the fonts in the composer scalebar and in the labels don't appear nicely with the open gl engine on my computer). Moving the duplicated content of the constructors to an init() method and replacement of it/else with switch is fine, so I'm going to commit that part of the pull request. Thanks for your contribution, |
Sorry, but what about unnecassery deletion and creation of QGraphicsRectItem in mouseEvent? |
Creation of QGraphicsRectItem is very fast, so I don't see a reason to store an item on demand for every existing composer item. |
removed duplicate code, openGL for drawing (if support of course), removed the unnecessary creation and deletion of QGraphicsRectItem.