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

Fix CanvasDrawer when viewport is flipped and a TiledImage is rotated #2511

Merged
merged 2 commits into from
Apr 12, 2024

Conversation

pearcetm
Copy link
Contributor

This PR should fix #2477 and incorporates some of the changes proposed in #2510, which addressed some but not all of the problems with the canvas drawing pipeline.

Based on my testing using the drawer comparison demo (http://localhost:8000/test/demo/drawercomparison.html), the two viewers now appear to work equally well in the cases that were causing buggy behavior before. A side benefit is that the code is a bit cleaner and easier to understand now too (though it is still somewhat complicated).

While fixing this, I also updated the debug info drawing code in the WebGLDrawer to incorporate the same types of changes since that was also broken in the same way.

…. fix webgl drawer debug info when viewport is flipped.
@eug-L
Copy link
Contributor

eug-L commented Apr 11, 2024

Nice, so you have separated the logic for flip and rotation, the viewport really only needs to flipped once, which makes it much clearer now!

I have tested most combinations of viewport & tiledImage rotation (+/- angles) they seem to be working well!

@@ -1067,63 +1071,85 @@
this._clippingContext.restore();
}

/**
Copy link
Member

Choose a reason for hiding this comment

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

This is so minor I feel silly mentioning it, but you've got a stray tab here...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

Copy link
Member

@iangilman iangilman left a comment

Choose a reason for hiding this comment

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

Awesome. Thank you both for collaborating on this!

@pearcetm How are you finding it is to fix things in both drawers together? Any thoughts about how this is going to be, for us to be maintaining them both?

/**
* Get the canvas center
* @private
* @param {Boolean} sketch If set to true return the center point of the sketch canvas
Copy link
Member

Choose a reason for hiding this comment

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

This isn't true.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed (jsdoc comment was copied over from CanvasDrawer)

@pearcetm
Copy link
Contributor Author

How are you finding it is to fix things in both drawers together? Any thoughts about how this is going to be, for us to be maintaining them both?

This bug in CanvasDrawer that we're addressing here also happened to affect the debug mode of the WebGLDrawer, because that code was originally copied over from the former canvas implementation. It certainly isn't ideal to have to fix things in two places, but hopefully there will be fewer and fewer remaining issues that affect both drawers after we get the initial kinks ironed out.

I thought about avoiding what is essentially duplicate code by making the WebGLDrawer call the CanvasDrawer prototype in order to draw the debug info. However, this has its own downside of coupling the drawer implementations more closely, and would mean that changes in one drawer could influence the other. A bigger refactoring of the debug message code into the base Drawer class might be the best approach...

Copy link
Member

@iangilman iangilman left a comment

Choose a reason for hiding this comment

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

Thanks for the fixes! And thanks for the thoughts... Sounds like we're on the right track. I agree it's good to keep some separation between the two. Probably the best strategy, like you say, is creating small composable functions that can be shared when appropriate, but otherwise leaving the logic separate.

@iangilman iangilman merged commit 4f2bcbb into openseadragon:master Apr 12, 2024
1 check passed
@pearcetm pearcetm deleted the fix-canvas branch April 12, 2024 16:24
iangilman added a commit that referenced this pull request Apr 29, 2024
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.

Tiles in FOV hidden while zooming for certain Viewport & TiledImage rotation combinations
3 participants