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

[Bug]: Visual artifacts when dragging dockable windows over map #3583

Closed
Irarara opened this issue Sep 2, 2022 · 7 comments · Fixed by #3584
Closed

[Bug]: Visual artifacts when dragging dockable windows over map #3583

Irarara opened this issue Sep 2, 2022 · 7 comments · Fixed by #3584
Assignees
Labels
bug tested This issue has been QA tested by someone other than the developer.

Comments

@Irarara
Copy link
Contributor

Irarara commented Sep 2, 2022

Describe the Bug

When moving dockable windows around over the map the area under the path of the dragged element is not getting repainted, resulting in a black trail (as well as sometimes entire chunks just getting drawn black?).

This behavior seems to have come with #3580.

To Reproduce

Drag a window around over the map.

Expected Behaviour

There should be no visual artifacts when moving windows.

Screenshots

MapTool Info

develop branch

Desktop

Windows 10

Additional Context

No response

@Irarara Irarara added the bug label Sep 2, 2022
@Phergus
Copy link
Contributor

Phergus commented Sep 2, 2022

@kwvanderlinde oopsie

@Phergus Phergus assigned cwisniew and kwvanderlinde and unassigned cwisniew Sep 2, 2022
@kwvanderlinde
Copy link
Collaborator

Interesting. Happens on Linux too ... if I move it using the title bar and not my usual technique of alt/win key + dragging the window. Will investigate this.

It's reminiscent of something else I've seen with overlays. When elements are hidden (e.g., menus), sometimes they leave black areas behind. Might be the same thing and I've just made it worse, or could be something entirely different 🤷.

@kwvanderlinde
Copy link
Collaborator

Ah, I've accidentally used the clip bounds for the buffer image size but then always drew the result at (0, 0) rather than the clip bounds coordinates. I could fix this particular error in logic, but a better approach performance wise would be to size the buffer according to the component and apply the clip to the buffer as well. PR to come shortly.

kwvanderlinde added a commit to kwvanderlinde/maptool that referenced this issue Sep 3, 2022
Rather than using the graphics clip to set a size for the image buffers, we now always size them to the component. This
is better for performance as we destroy fewer buffers, and easily avoids clip-related bugs like RPTools#3583.
@Phergus
Copy link
Contributor

Phergus commented Sep 3, 2022

Got a PR inbound?

@kwvanderlinde
Copy link
Collaborator

Yep 😄

@Phergus
Copy link
Contributor

Phergus commented Sep 3, 2022

Now if I can just get Github to cooperate.

@Phergus Phergus added the tested This issue has been QA tested by someone other than the developer. label Sep 8, 2022
@Phergus
Copy link
Contributor

Phergus commented Sep 8, 2022

Tested. Artifacts are gone now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug tested This issue has been QA tested by someone other than the developer.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants