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

Simplify the updatetextlayermatches event handling in TextLayerBuilder #10554

Merged
merged 2 commits into from
Feb 16, 2019

Conversation

Snuffleupagus
Copy link
Collaborator

This implements the nice suggestion from #10099 (comment), which I at the time didn't think would work. @timvandermeij I'm sorry about that!
I'll probably have to plead temporary insanity here, since it should have been totally obvious to me how this could be implemented. By simply not registering the event until the textLayer is actually rendered, removing the event on cancel works just fine.

This patch also removes the pagecancelled event, given that it's no longer used anywhere in the code-base and that its implemention was flawed since it wasn't guaranteed to be called in every situation where rendering was actually cancelled.

…lder`

This implements the nice suggestion from mozilla#10099 (comment), which I at the time didn't think would work.
I'll probably have to plead temporary insanity here, since it *should* have been totally obvious to me how this could be implemented. By simply not registering the event until the `textLayer` is actually rendered, removing the event on `cancel` works just fine.

This patch also removes the `pagecancelled` event, given that it's no longer used anywhere in the code-base and that its implemention was flawed since it wasn't guaranteed to be called in *every* situation where rendering was actually cancelled.
… artifacts when called directly

Currently these methods are only used from the respective `reset` methods, and from `{BaseViewer, PDFThumbnailViewer}._cancelRendering` which only runs when the active document is closed.

This patch changes `{PDFPageView, PDFThumbnailView}.cancelRendering` to *only* cancel any pending rendering operations, and doesn't attempt to reset e.g. the `renderingState`, since that causes visual glitches (duplicated canvases in the viewer) when called directly.
Furthermore, unless you "know" what you're doing, the `{PDFPageView, PDFThumbnailView}.reset` methods are what *should* normally be used instead.
@timvandermeij
Copy link
Contributor

/botio-linux preview

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Received

Command cmd_preview from @timvandermeij received. Current queue size: 0

Live output at: http://54.67.70.0:8877/e405071faa33be2/output.txt

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/e405071faa33be2/output.txt

Total script time: 1.77 mins

Published

@timvandermeij timvandermeij merged commit b6f5819 into mozilla:master Feb 16, 2019
@timvandermeij
Copy link
Contributor

I'll probably have to plead temporary insanity here

No worries! Thank you for simplifying the implementation.

@Snuffleupagus Snuffleupagus deleted the rendering-cancelled branch February 17, 2019 01:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants