Forums | NoesisGUI

Hi there,

As our app is handling an increasing amount of pictures, I've just start using atlas and imagebrushes to simplify their integration and improve performances.

However, the Android apk is now XXL, and it seems to be related to the size of the pictures in the android sharedAssets folder (no pb on windows).

I've dug the forum, and found that the image compression was not active on android on late 2014 - but it was on the roadmap. Is this issue still persisting, or is there any way to enable texture compression on android ?
Otherwise, how should I proceed ? I know I can load my textures on the fly from any Resource folder, crop them, process them (for they're using an alpha channel), and set them as bitmap source, but I'm afraid that the perf will be heavily impacted by this process.

Another related question : is there any elegant way to "reduce" the resolution of the image being used by Noesis at build time (my atlas are 4096*4096 for Windows, and I'd like to have them on 2048*2048 for [Edit]ANDROID) (so, without breaking the coordinates being used by the ImageBrush Viewboxes ?), or shall I preprocess everything in order to reduce the quality ?

Regards,
Roland

I've dug the forum, and found that the image compression was not active on android on late 2014 - but it was on the roadmap. Is this issue still persisting, or is there any way to enable texture compression on android ?

Unfortunately there is no way to enable texture compression for XAML images.

Otherwise, how should I proceed ? I know I can load my textures on the fly from any Resource folder, crop them, process them (for they're using an alpha channel), and set them as bitmap source, but I'm afraid that the perf will be heavily impacted by this process.

I suggest to use Unity textures directly, so you can control all texture options (including compression) in Unity. This can be done by creating a TextureSource from the UnityEngine.Texture and set it as Image.Source or ImageBrush.ImageSource.

Another related question : is there any elegant way to "reduce" the resolution of the image being used by Noesis at build time (my atlas are 4096*4096 for Windows, and I'd like to have them on 2048*2048 for [Edit]ANDROID) (so, without breaking the coordinates being used by the ImageBrush Viewboxes ?), or shall I preprocess everything in order to reduce the quality ?

No, you cannot use different texture sizes with the same ImageBrush definition. But you can have different ResourceDictionaries to define the atlas ImageBrushes for Windows and Android, and depending on the runtime platform add one or another to the UI tree.

Hope this helps.

Ok, thanks !
I've finally prepare a set of batches to reprocess my atlases and dictionaries from the various targeted platform.

Unfortunately there is no way to enable texture compression for XAML images.

Is it something being envisaged on your roadmap for the middle / long term ?
Just because I'm curious, is it technically not possible or simply not a value for the Noesis Framework ?

Thx,

Roland

Is it something being envisaged on your roadmap for the middle / long term ?
Just because I'm curious, is it technically not possible or simply not a value for the Noesis Framework ?

Let me explain this a bit better, sorry for the confusion. There is compression implemented in 1.2, but only for desktop (D3D and GL). It was never implemented for mobiles. Your best workaround right now is the way described by Sergio, using texture objects created by Unity, binding to TextureSource in the VM for example.

In fact, in 1.3 this is going to be the only way to use textures in Unity3d. The build step we perform in Unity right now is going to be deprecated. The plan is using the texture created by Unity. That way, the user have total control with the process of converting image files to render textures.

Is it something being envisaged on your roadmap for the middle / long term ?
Just because I'm curious, is it technically not possible or simply not a value for the Noesis Framework ?

Let me explain this a bit better, sorry for the confusion. There is compression implemented in 1.2, but only for desktop (D3D and GL). It was never implemented for mobiles. Your best workaround right now is the way described by Sergio, using texture objects created by Unity, binding to TextureSource in the VM for example.

In fact, in 1.3 this is going to be the only way to use textures in Unity3d. The build step we perform in Unity right now is going to be deprecated. The plan is using the texture created by Unity. That way, the user have total control with the process of converting image files to render textures.

Ok, got it ! I'll adapt my workflow to take this into account.

Regards,

Roland