MobileSheets Forums

Hi,

I've just migrated from using MobileSheets on Chrome OS to a new Microsoft Surface Pro 11 on Windows ARM. For some reason zooming during annotation is lagging a lot and is causing a huge spike in RAM usage. Idling with a PDF open uses about 400MB; zooming in (but outside of annotation mode) goes up to 700-1000MB (but there is no noticeable lag); zooming in in annotation mode on a PDF with no annotations goes up to 1000MB; but when there are annotations, it spikes up to 3000 or even 4000MB ram, and there is a lot of lag. I've tried messing with the various display settings - using the GPU or not, render preference on speed or quality, changing whether highlights are drawn behind or not - they don't seem to make a difference. Any ideas how to fix? Thanks.

This is an unfortunate consequence of the implementation of some of the Skia rendering controls that are available for C# applications, and the way that zooming is implemented in MobileSheets. The rendering component is backed by a bitmap that is sized to match the scaled size of the view. As you zoom in, the size of the view changes, and the rendering component allocates a new bitmap to match the size of the view. This utilizes an extremely large amount of memory when you zoom in a considerable amount. This is made worse by the fact that I have multiple of those rendering controls stacked on top of each other for each page for performance reasons (so that the rendering of annotations, link points, etc, is separate). That is why you are seeing such a huge spike in memory usage while zoomed in. To improve this situation, I will have to make a number of changes, none of which are simple. The easiest change that I'll make is that I'll no longer using separate drawing components for link points or annotations. This could have small performance implications (every annotation will be redrawn any time you tap a link point or smart button, or while the link point is fading out), but it will dramatically reduce memory usage. A harder change with greater benefits would be to limit the size of the rendering components to only be as large as either the parent view or the screen, whichever is smaller, but then the rendering code and touch coordinate processing will get significantly more complicated, and this is likely to introduce small bugs if I'm not careful.

On Android, every component is hardware accelerated by default, and it makes all of this significantly easier, as the framework is smart enough not to waste resources on things rendered off the screen. iOS is similar in this regard.

Mike

Thanks so much for your detailed response - it's totally workable for now, but looking forward to seeing improvements in the future. Thanks for all the hard work you do on this app, it's very much appreciated. Cheers