Performance issues during panning/zooming

[Simon-Dirks]

Hi there,

I noticed that when I turn on the OCR layer in my Angular project, panning/zooming became choppy. When I turn the text overlay back off again, it's much smoother. At first I thought it might be related to my Angular configuration, but I've reproduced this in a basic vanilla JS project as well. I've created a repo with a video that shows what I mean: https://github.com/Simon-Dirks/mirador-performance, but will also include the video here (running in Firefox, M1 Pro MacBook):

textoverlay-performance-demo.mp4

My best bet at the moment is that it's not necessarily related to the plugin code, but simply that changing the SVG container's transform is a relatively heavy DOM/browser operation, especially when there are many text elements. I was thinking perhaps the number of transform updates could be reduced or debounced to improve performance. From what I saw from the plugin's code, however, there were already various fixes and hacks to focus on performance, so I was wondering if what I'm seeing is "normal"/expected behavior, or if perhaps I've misconfigured something.

[Simon-Dirks]

Running into the same behavior on the demo site: https://mirador-textoverlay.netlify.app/

[jbaiter]

Yeah, this is a bit of a pain point with the plugin :-/ Whether or not you're hitting 60fps is basically dependant on whether the browser uses GPU acceleration for the CSS transformations on the SVG.
As you noticed, we already have a few things implemented to help the browser make that decision more often:

• Only use CSS transforms to modify the SVG during pan and zoom (should directly map to GPU ops if the SVG was rendered to the GPU)
• Set will-change: transform on the SVG element to tell the browser that rasterizing it to a GPU texture is probably worth it, since we're going to be transforming it frequently

But in the end it comes down to details in the rendering pipeline on your hardware, possibly the heuristics for deciding when to rasterize to a GPU texture are different enough for Apple's SoCs that we're not hitting that path with the plugin :-/ This is all compounded due to the fact that the SVG is a transparent overlay over a Canvas that has its own surface, so the decision path is likely to be even more complex.

Have you tried Chrome? Does it exhibit the same issue?

Also a note on why the SVG rendering path was used instead of rendering the text directly onto the canvas (which would likely be more performant): Text selection (or generally, nice text rendering) is a pain on the Canvas and needs a lot of work to get it right and feel good across different environments. With SVG we get all that for free.