Main screen scrolling jittery/laggy

[corobin]

I've noticed that on the main screen with all the cards, scrolling up and down is regularly jittery or laggy, like, instead of smoothly scrolling there will be jumps/skips down or up. i found this most noticeable going away and to one of the top or bottom edges of the page (e.g. when scrolling back to the top, it'll scroll - not smoothly - to just the bottom sliver of the top cards, then jump directly to the very edge without scrolling past the rest of the top cards), less so in the middle but it is still observably there.

i tried to take a screen capture of it but on the video it looks much smoother than in real life, so potentially this has something to do with the rendering on the phone screen itself.

on a test with no card images, it scrolled fine, but once i added card images, the behaviour began. potentially related to #638 however what i'm seeing is not limited to the initial scrolling, it persists. i also noticed no lag in the display of the card images. only scrolling seems to show an issue.

pixel 7 android 15 latest patches
catima 2.34.4

[TheLastProject]

Hmm, I thought this was only an issue on like really slow devices, but a Pixel 7 is surprisingly recent.

I did create #1933 before which definitely helped with the but it felt worse as it showed the text before the image, so it felt like things were "flickering". Perhaps it would be worth revisiting that MR with some kind of "loading" image (animated or not) and see if that feels better.

[corobin]

since it didn't show up in a screen recording I'm not sure that it is entirely to do with the image rendering within the app itself. although i ran some more tests and reducing the image resolution from what i had before did improved it significantly. maybe it's as simple as specifying a max image dimension and auto resizing if that is exceeded? the app generated size of 512px across seems to be ok.

[TheLastProject]

As I understand it, it is not the image rendering that is causing the slowdown but the loading it from disk, this is done synchronously right now (on the rendering thread!), #1933 makes that async. Smaller images generally mean smaller filesizes and thus faster loading from disk, which is why reducing the resolution could help.

maybe it's as simple as specifying a max image dimension and auto resizing if that is exceeded? the app generated size of 512px across seems to be ok.

I'm a bit confused here, doesn't Catima already limit it by 512px? Or is the logic wrong in some way?

[corobin]

As I understand it, it is not the image rendering that is causing the slowdown but the loading it from disk, this is done synchronously right now

oh, that makes sense!

does the app support SVG for the images? that would probably deal with this nicely and has the added bonus of high fidelity images of arbitrary size on any phone screen.

I'm a bit confused here, doesn't Catima already limit it by 512px? Or is the logic wrong in some way?

oh i'm not sure if it does if i add an image via the app. i made custom images for all my cards and the easiest way to set them was to replace them in the catima export file and re-import it. when importing it accepts images of arbitrary size and does not re-size them after, despite having reprocessed them.

i.e. if i import it with custom made images, and then export it again, the exported images are different from what i imported but are the same dimensions.

[TheLastProject]

does the app support SVG for the images? that would probably deal with this nicely and has the added bonus of high fidelity images of arbitrary size on any phone screen.

Not currently, there's an open feature request on #1142 but I haven't spent any time into it :)

i made custom images for all my cards and the easiest way to set them was to replace them in the catima export file and re-import it. when importing it accepts images of arbitrary size and does not re-size them after, despite having reprocessed them.

Manually editing backup files is not really a supported use case 😅 I did take a quick look at the current code and created #2381, because I do think making the importer more resilient can't hurt.

Anyway, I'm glad to hear the performance is better now and re-exporting a manually edited import is a "workaround" to ensure your export file is sensible again, but to scale the image loader for slower devices (or for those who set the column and row values quite high), #1933 is probably the more correct path (but both issues are helpful to look into) :)

[corobin]

Manually editing backup files is not really a supported use case 😅

ya i figured after we started having this discussion but with the open nature of the app and format (which is great 👍 thank you!) it didn't even occur to me earlier. i just thought it was a easy way to apply all my images at once.

and re-exporting a manually edited import is a "workaround" to ensure your export file is sensible again

just to clarify, re exporting does not currently resize the dimensions. it stays the same dimension as whatever was imported.

[TheLastProject]

Ah, good to know, I misunderstood you then :)