Textures and the virtualizer

[AeroShark333]

Hello,

But when I virtualize textures, then the textures shown on my Object3Ds are just black sometimes.

I use the virtualizer for my live wallpaper.
And it seems that when the textures do load properly for the actual live wallpaper of the homescreen, it does not work for the live wallpaper preview/apply screen.
And when it does work for the live wallpaper preview/apply screen, it does not work for the actual live wallpaper.
This is not always the case... but it is hard to reproduce this...

Is there some conflict perhaps between two different activities/services trying to virtualize?

Can this be fixed or am I doing something wrong?

Cheers,
AeroShark333

[AeroShark333]

I guess it was a mistake on my side...

This solved my problem:

Code Select Expand

if (textureManager.getVirtualizer() == null) {
final Virtualizer vz = new Virtualizer();
vz.setContext(getApplicationContext());
textureManager.setVirtualizer(vz);
System.out.println("New Virtualizer set!");
}else{
System.out.println("Virtualizer has already been set!");
}

[EgonOlsen]

Creating a new instance on each resume/context change is against the basic idea of the virtualizer, so your solution is fine.

[AeroShark333]

So... I have had two users of my app saying that their phone broke thanks to my application.
And I was utterly confused how that could happen.
My app barely uses any permission.

So the only thing I could think of that could have caused this, was the Virtualizer.
Is it possible? Since I think the Virtualizer is basically the same thing as swap.
And I do know that swap can degrade the lifetime of a sd-card.

My app is a live wallpaper.
Both users were using a Galaxy Y.

[EgonOlsen]

No, it's not swap in the usual sense. It just writes the texture data to the sd and reads it back, if it uploads the texture to the GPU. As long as the context doesn't change, there's no difference if you load a texture directy or via the virtualizer. Normal Android background operations or web browsing will most likely cause more IO than the virtualizer.
I really don't see how one can draw the relation from your app to a broken (whatever that means...) device. It could be anything. Just the fact that your app was running (which is only natural if it's a wallpaper) doesn't mean that it's in any way responsible for this.
End users are...difficult. They usually have no clue what they are talking about, have no proof of anything but they always have an opinion. And it's never them who's responsible. It's always somebody else. So as long as the Galaxy Y has no design flaw that causes this, I see no relation. And if it has...so be it. You can't fix Samsung's shit. If you want to be sure, you can exclude that particular device in Google Play, so that people which are using it won't see your app in the store (I think you need the proper internal name for that, not just Galaxy Y).

[AeroShark333]

Hmm, I see. Thanks for the reply.

What will the Virtualizer do when the SD card is (almost) full?

[EgonOlsen]

It's supposed to fail and the app should continue without all textures being written out onto the SD. I tested this in an artifical test only, because I never ever encountered a 100% full SD in the real world.