converting to astc spawned a terminal for every image, probably a windows thing that can be sorted out.
nice catch, i always run from vscode terminal so i dont notice these things.
EDIT: forgot about this while typing the reply below, fixed that problem below but not this one xD, this is up next.
whats alil weird about load times is if I scroll at a medium speed, it loads everything instantly.
whereas if I scroll fast, it takes a second to catch up to loading the newest images in view. looks like a bottleneck somewhere, maybe its not cancelling the render calls for images that are now out of view, or its set as FIFO?. but anyways that's a low priority optimisation given how fast things are already!
youre right, i see this too. and youre about right.
each frame when an image is shown that is not loaded, it gets put to the top of stack of images (LIFO) to load (thats why it loads from bottom right, because when theyre all shown at same time, its drawn top left to bottom right, so bottom right is the last image drawn, which goes to top of stack as first one to load).
then, images in the stack are processed one at a time. means that if a new image is added to top of stack, if theres one currently still loading, it has to wait for that one to finish.
for how its currently architected, cancelling loading an image is kinda complex, im not sure i trust myself to do it properly without race conditions.
anyway, after an image is loaded, it gets added to a queue to be applied (sending the loaded texture data to gpu). this currently is FIFO, but thats not the whole problem.
i had it limited to 1 texture apply per frame, otherwise it would apply all images in one frame and stutter really badly. so, its FIFO, and "ratelimited", so scrolling by super fast would load all the ones you go by instantly due to being ASTC, then they all get queued, and they take time to apply the ones off screen, just to unload them right after as they are offscreen.
the main issue i just fixed by removing images off-screen from the apply queue, as i mentioned i dont trust myself to interrupt the load process (which includes conversion if applicable), but removing the image from apply queue is simple and effective, and fixes the issue basically entirely.
as for without unloading offscreen images, FIFO still seems to work better for applying... logic tells me otherwise, but yeah... with LIFO applying, it takes a while tostart applying the images currently shown on screen, with FIFO theyre loaded immediately when shown (talking about ASTC without unload, without ASTC it would load slower but same effect).
anyway this issue is resolved in build 1437
EDIT: alil rabbithole diving into astc, seems adoption is slow due to S3TC & BC7 being "good enough" compared to astc, albeit astc being slightly better. potential fallbacks if astc is not supported?
S3TC is the specification for DXT1/3/5, and i think BC7 is part of BPTC which i also tried. they all look like shit, so idk what these clowns are on about xD
looks like astc is the perfect candidate.
for hardware that doesnt support it, you can have a fallback to opengl at the cost of quality for people who prioritize lower vram use
i was moreso thinking of just letting people disable compression altogether. but i have one last hope that i need to check. if we are incredibly lucky, maybe opengl can convert ASTC to RGBA before uploading to gpu, if its not supported. if thats the case, we could benefit from disk space savings and *maybe* load speed too, at the cost of VRAM, but that is again offset by unloading off-screen images.
FaceCrap 's gpu seems to not have ASTC, but the error he encountered thus far was due to the encoder, not the gpu loading the texture. we'll see what his gpu says when presented with valid ASTC then decide what to do. if it cant decompress ASTC to RGBA live then yeah as you said, loading RGBA and letting opengl compress it to DXT1 would be a good enough alternative to allow lower VRAM (but of course wouldnt work well with unload off-screen images). also if we end up doing that, the ui freezing like before wouldnt happen anymore (atleast not to that degree) as only one image is applied per frame, so only 1 would need to be compressed by opengl per frame.
