On my system (Frescobaldi 4.0.3, native archlinux package) zooming in on the pdf view increases memory usage (also having a big spike during and rendering) and computation time. This means that setting zoom too high will result in Frescobaldi freezing and producing tons of RAM to eventually crash.

Just to get an idea: With one particular score Frescobaldi sits at 515M at 100%. At 214% rendering is almost instantly, and we sit at 655M. At 418% it taskes only a minimal delay, and memory sites at 822M. At 814% we are at 958M. At 1083% Redering takes maybe half a second, memory peaks to 3.2G and falls back to 1.1G. At 1745% we take maybe 1 second and a peak of 7G which falls back to 2.3G. At 2323% memoy peaks to over 12G and falls to 3.5G.

Looking at these measurements

it seems reasonable to think that memory of the viewer scales roughly by the square of the scale, which makes me believe that Frescobaldi generally renders the whole score at the given scale, rather than just the current area. This of course means that once rendering is done we get very smooth scrolling, but is means scrolling is chunky and requires a lot of memory.

Now, this comes at an even bigger issue: Once you reach a certain level of zoom (~ 1000%) due to the freezing it becomes hard to adjust your zoom when zooming with mousewheel, and actually (even when doing [Ctrl]+[+]) this input event seems to be duplicated, resulting in Frescobaldi doing multiple zooming steps after each other. This does as well apply to mousewheel zooming.

Now, what this means that when zooming in (e.g. to check alignment of some things) not only the zooming experience is not nice, but also once you go over a certain level Frescobaldi starts doing multiple steps and crashes due to high RAM demand, which is clearly not ideal.

Of course what should actually happen is that the score is only rendered in say cached chunks around the current view. E.g. when I open the file in Okular and zoom in to even 10000% memory barely changes, but once I start scrolling around memory will rise to some point, at which Okular is dumping cached tiles and memory keeps constant. This leads to really fluent zooming, but more CPU for scrolling after, which is probably fine. What we can also see with Okular is that rendering is done in a separate thread, keeping zooming and scrolling totally smooth while content is rendered. Meanwhile Frescobaldi totally freezes up when rendering, including the Code pane, the menu, probably saving and stuff.

But this is probably not going to be trivial to implement, so I’d suggest to at least limit zooming level to maybe 800% to avoid crashing people’s sessions when they try to zoom in using mousewheel.