Skip to content
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

[3d] Fix unnecessary terrain map updates when changing 3D renderer #9839

Merged
merged 1 commit into from Apr 23, 2019

Conversation

wonder-sk
Copy link
Member

When using layer styling dock, every change in 3D rendering configuration
was also triggering update of 2D map which also forces update of all
terrain tile textures with a new 2D map which wasn't really needed.
The fix makes the triggerRefresh() call on layer optional - each layer
styling dock config widget can tell whether its updates require 2D map
refresh (true by default).

When using layer styling dock, every change in 3D rendering configuration
was also triggering update of 2D map which also forces update of all
terrain tile textures with a new 2D map which wasn't really needed.
The fix makes the triggerRefresh() call on layer optional - each layer
styling dock config widget can tell whether its updates require 2D map
refresh (true by default).
@wonder-sk wonder-sk added this to the 3.8 milestone Apr 21, 2019
* (for example 3D rendering config) do not need layer repaint as they do not modify 2D map rendering.
* \since QGIS 3.8
*/
virtual bool shouldTriggerLayerRepaint() const { return true; }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would a flags based approach be more appropriate here? I'm 50/50

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally my feeling is that flags are better when a class is made to be used as is and flags can modify its behavior based on caller's preference. When a class is made to be derived and the behavior is defined by the implementation of derived class, a virtual method feels better. But no strong opinion...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants