Small textures & load time

I've been using 2 64x64 textures on a HUD but the load time on them is really awful at 3-4 minutes after wearing the HUD.

I wondered if it was due to the fact that the textures were lossless (one texture contains 8 16x16 icons so regular compression makes a mess of them) but even though load time is slightly better as a lossy 64x64 (about 1-2 minutes) it's still rather unacceptable.

On a hunch I resized each 64x64 into a 512x512 and much to my surprise they now rez in mere seconds as they should.

Am I missing something?

(I know we used to have a bug where textures from prims attached to HUD would have an awful load time, but opening the small vs big texture from inventory, or applying either to a rezzed prim shows the same behaviour: bigger textures seem to rez much faster than small ones when their surface area is the same).

Is there some part of the process that converts all textures to the same size, making textures that start at that size load faster than any other size because they don't have to be converted in size?

This is just a guess.

Interesting guess, Sharcel, but no, that's not how it works.

There's often little apparent rhyme or reason to how quickly assets load. All things being equal, of course smaller items would appear before larger ones. But when dealing with networked databases, things are rarely equal. There are all kinds of chaotic factors in play that can alter the results of this kind of test. Do it on a different day or in a different location or on a different computer, and the results could be very different.

Also, LL does from time to time play with forcing the delivery order. Sculpt maps, for example, were supposedly given higher priority in one of the recent updates (and man did they need it). It's not out of the realm of possibility that 512x512's also could have been given an increased priority. I'm not sure why LL might do that, but they certainly could.

Well, I can think of one reason LL might choose to prioritize 512 x 512 textures, and that is the fact that all skin and clothing should be using that specific size. So by prioritizing 512 x 512 textures, you would make skins and clothes set up faster than, let's say, a mailbox that's painted with a smaller texture, or a billboard painted with a larger one. But that's just conjecture.

I've seen JIRA entries on several occasions complaining about HUD textures taking a long time to load, or remaining blurry. Sounds like there may still be a current bug in that regard. I know a few of the HUDs that I have from other content creators do have some textures that load perfectly, while others remain fuzzy. While at the same time other HUDs from other makers are always crystal clear.

I'm working on a HUD right now for an orientation course, and I decided to do it all with textures that used a 512 x 512 texture sheet. It loads really fast, and is never blurry. The individual prims that you see change their textures as needed by scripted changes of the offset values, displaying the desired parts of the texture sheet.

I always thought avatars were control by outfit composite limits? and everything else by size and distance (neither of which seemed to apply to sculpt maps, hence the change), with priority added to items in focus (possibly in view but I never delved that deep)...

If that was the case then the 512x512 wouldn't load instantly while the 64x64 stalls for 2 minutes before it starts downloading again.

And it doesn't seem to really make any difference what the texture(s) are applied to: opening them from inventory (after a clear cache obviously) exhibits the same behaviour. The 512x512 and 256x256 are there right away while the 64x64 ones take minutes to rez in.

Same when applying them a to prim rezzed in-world.

"Avatar composite limit" has been out of preferences for a while now and with their (stated) focus on making less raw clothing/skin textures available it might just have been removed entirely.

For the rest I think "size and distance" are really just combined into one number which loosely seems to mean "how much screen area is taken up by the texture".

Which also shouldn't apply in this case since 1) there's nothing pending so really nothing that would keep either from just downloading right away and 2) the texture area should just be identical in both cases since it depends on the camera vs prim size rather than texture size.

I have extensive experience in tweaking and optimizing loading times and getting around bugs for lossless images, as I am a sculpt designer. Whether what I've learned applies to _lossy_ images that SL uses, I am not sure, but it seems likely. Here's some relevant snippets from a tutorial to optimize sculpts for loading time I am writing:

1) Overview of How JPG 2000 Lossless Works

In a traditional uncompressed, lossless format such as bitmap, the image has a fixed file size regardless of the data; every pixel is represented with a value. In contrast, normal jpg images are compressed lossy, not specifying a value for every pixel but rather approximating the image. This doesn't work well for sculpts because for most uses, having precision is essential. And so, JPG2000 lossless images are used. This format preserves all data, but vaguely works similarly to GIF; images with repeated pixels of the same color, or close in color range, compress better than if the pixels are all disparate. On the extreme end of uncompressability would be an image of color static with every pixel a unique value and wide variation between adjacent pixels. On the extreme end of compressibility would be a solid black image.

3) Overview of how SL downloads images.

When the SL client downloads a texture (sculpt or image), it "expects" a certain amount of data up to a threshold, and downloads in steps up to that threshold. For regular lossy jpg images (normal textures), there was no problem, because the lossy compression made most images quite similar in size. The story with lossless (sculpt) maps is quite different. The old lossless bug, fixed in May, was due to the file size being larger than the threshold size, so that not all the data would be loaded. This bug is fixed (thresholds increased/tweaked) but the general principle remains.

For one, what this means is that if two sculpts are the same dimensions, and one smaller in file size, the smaller one will load faster- as expected. But more peculiarly, it means that if a 64x64 image is resized to 128x128 using nearest neighbor resampling, the 128x128 will load faster. This is because images of different dimensions (pixel counts) have different "expectation" levels, and by resizing it but keeping the range of values, the 128x128's ratio of file size to expectation is higher than the 64x64.

---------------------

Keep in mind that I am not a coder, and the above is based on my knowledge of being a sculpter and interpretation of what coders and Lindens have told me. I have however tested the above; it isn't based on just intuition.

From what you describe, you are encountering similar strange issues with small images loading slower that sculpters experience using lossless images. I suggest resampling the image(s) to different sizes (using nearest neighbor resampling!), going to a skybox, placing them on prims, and detaching all attachments. Then clear cashe and relog, and compare loading speeds. There should be an optimal size that may not load the fastest, but comes close, and doesn't take up the extra texture memory that larger images do (when scaling up, one reaches a point of diminishing returns.)

Also, wide variations in adjacent pixel values make the image harder to compress losslessly, increasing in larger file size- and thus slower loading times. For many sculpts this isn't a huge issue because in general adjacent pixel values are relatively close together. As for small textures that need lossless compression, they have lots of variation in RGB values between adjacent pixels.

Another thing to try is to splice multiple textures onto one image sheet. For example, 4 64x64's on a 256x256 image.

If you use a bunch of small textures in a build, HUD, or whatnot, you should combine them into texture sheets. That helps everything load faster because it's less individual UUIDs that have to be looked up and delivered by the asset server. It can really make a big difference.

Yea, that
TL;DR version of my above post: lossless is a bad idea for textures

That's what I'm doing already though .

One 64x64 has the 16 16x16 icons, the other 64x64 has the 2 button states and the background.

Thankies muchies for that .

The two 64x64 were actually uploaded lossless since it's actually a 4x4 grid of 16x16 icons and the compression just makes a mess of them.

What you wrote does fit with what I'm running into so I guess I'm stuck with enlarging everything by a factor of 16 which seems to keep the lossy artifacts to a minimum and loads quickly. Next time I won't bother trying to be texture size efficient .

(I love your trees btw )

I just tested this and I'm not getting those results. Loading a 512x512 clothing texture from inventory is taking 40-60 seconds (pitiful, BTW) in a skybox in a low-density mainland sim which I mostly own, at a time when everything has long since rezzed. A 128x32 is taking about 5 seconds.

I believe the viewer logic is to prioritize textures by how many pixels they take up on your screen. My experience says this happens even if they aren't visible. That is, the wall texture outside the store behind the wall you're looking at will rez faster than the vendor texture you're looking at.

Avatar textures may be prioritized differently, though.

If Aminom's explanation/guess is what is actually happening then it wouldn't happen on all textures, just those textures who happen to be uploaded lossless or were uploaded lossy but where their size is above a certain threshold size.

(You're right that textures are prioritized based on how much "space" they're taking up on the screen, but if I open them from inventory and size the 64x64 as large as it will go and the 512x512 as small as it will go or if I apply the 64x64 to a large prim and the 512x512 to a small prim the 64x64 still exhibits the same stalling)