Yeah I was shocked no one seem to have made one yet!

if you want...i can throw a few things over your way. i think i know a few of the issues you're having there.

2 3

i think im running the latest version, and im seeing the transition issue when i open an image (obviously expo-image is reloading the image). a few things we can do to fix that (i'll look at the code here soon too and actually verify these are the issues...)

for one, see if using expo-image 1.8 causes any issues for you (it shouldn't, i think the breaking changes are in 1.9). i added a few PRs there for image prefetching (also fixed some issues with GIF performance and start/stop animation, which might help you out as well but is unrelated)

what i personally do is prefetch the necessary images once i get the feed data. the default now is to cache to both the disk and to memory. then, if we set cachePolicy to "memory-disk", as images get loaded into the view they will be stored in the memory cache

if you use memory-disk both in the feed *and* in the image viewer, there will be only a *very* minor delay in the subsequent loading (especially since bsky images are so small anyway). and finally, what we want to do is change how the modal works.

the image inside of the feed should *not* be resized. all we want to do is present a modal with the image originally in the same position as the one in the feed. it will quickly load "ontop of" the image in the feed, so there is zero noticable delay in the loading

and finally, you can set the opacity of the image in the feed to zero while the modal is open, so that when you close the viewer it *looks like* a single image is just moving back to the original position. (using a set timeout of 100ms or so, again to prevent weird issues with the delay)

sorry for the long and maybe incoherent thread...if you have discord or something im happy to share some stuff there if thats easier 😅

Samuel 6 Dec 2023

Yeah super helpful! - you can find me on discord: mozzius sounds like the way to go is switch from the viewer being a different screen, with a SET, to a custom modal thingy

super briefly (and i can just share code too later when i get home) i have my app wrapped in ImageViewerContext, which has a modal. Whenever I press on a ViewerImage (what is in the feed), it updates the state of the modal with all the necessary info and toggles its visibility.

i need to clean up the code a bit (its honestly a mess of logic, i see why there are not any good image viewer packages available!) but i should probably just put it on npm

Samuel

@samuel.fm

Yeah I was shocked no one seem to have made one yet!

you and me both. there are a few (the one bsky uses is quite old and is partly using a scrollview (lol)) that either use the old animated api or are just not customizable at all. having to roll my own was a pita, but i feel like ive just *absolutely* mastered reanimated 😅

1 3

(don't worry, i'll encounter an obscure reanimated error sometime later this week and be crying)

1 3

i think we ended up forking/rewriting a lot of the one we previously used, see here github.com/bluesky-soci... it’s still structured similarly but uses reanimated now and any ideas on improving are welcome! i really want to get the transition in too but not sure how yet

2 6

also, i *think* i saw you (similar or same avatar?) had opened an issue about expo-image on android causing issues. did that ever get cleared up? have you guys tried doing anything with image prefetching to help with the unloaded images when scrolling?

2 2

for the record (unsure if this is something that was a concern or not, but i know it caught my attention) prefetching in a dev build shows *insane* memory consumption. it's managed fine though in a prod build (profiling on ios gives me around 50-80MB of memory usage while scrolling feed)

1 4

could this be due to every avatar being 1000x1000? i know it’s super clowny but haven’t followed up on getting this fixed yet. also idk how to profile memory so i need to learn that

1 5

https://i.imgur.com/zBd3t4G.mp4

that's definitely part of the issue. while i scroll, it looks like images are not yet fetched (since the flatlist has not yet rendered the item), so i get a jarring render once that happens. i.imgur.com/zBd3t4G.mp4

i.imgur.com

avatar size *shouldn't* be as big of a deal though, since you can set the cache policy on those to disk. the vast majority of avatars are just going to keep being reused (definitely should be smaller though regardless!) the post images are the bigger issue

is your proposal to prefetch images based on the data?

that's what i personally do here (as well as in another social media app). inside the query (i am doing some data transformations, so i do it while i do those transforms) i build an array of images to prefetch.

1 more reply

that issue got fixed, it was some metaprogramming they’re doing in expo modules being slow in kotlin. they switched to java apis to fix it. that was specifically startup time related tho, one-time cost

2 4

ah alright. all i do on android is test, so i was just curious if there was some lingering issue still there or not 👍

i’m not familiar with problems re: scrolling and unloading. btw one thing we need to fix is that currently all avatars are huge images

Samuel 7 Dec 2023

What’s the plan there - extra avatarThumb field or something?

anticipating bikeshedding that is actually what i got stuck on

oh yea, i took a look at it. you guys *significantly* improved what was already existing, so props there. its not a trivial task to get this thing right so... i have not implemented scrolling through images yet, but i'll likely just use a pagerview inside the modal for that