Android Question OpenGL Textures

[yttrium]

One of the largest issues with B4A is the dreaded OOM (Out Of Memory) error. I began running into this myself, as my application is a heavy image manipulation app. While my issue can be solved by android:largeHeap="True" this is not the best solution for many applications.

While researching, I've discovered that while bitmaps count towards the 16MB/24MB/etc per-app memory limit, apparently OpenGL textures do not.

Is there a way to implement this or use it as a substitute in B4A? Can these textures even be referenced like bitmaps?

 

[Erel]

One of the largest issues with B4A is the dreaded OOM (Out Of Memory) error.

This is not really related to Basic4android. Large images require a lot of memory. In most cases you can load the images with LoadBitmapSample and make sure not to load the images multiple times.

About OpenGL: http://www.b4x.com/search?query=OpenGL

 

[yttrium]

In most cases you can load the images with LoadBitmapSample and make sure not to load the images multiple times.

Sadly my case is one of the few where you can't.

I'll take a look at third-party libraries, I was just wondering if this was an optimization of sorts that could be made in the backend, since it's a bit harder for us to manage memory effectively without Reflection.

 

[Informatix]

If you understand how it works, you can use the Native DirectBuffer library.

 

[yttrium]

If you understand how it works, you can use the Native DirectBuffer library.

When it says

The library use jni "C" code compiled .so files to make the buffer outside of the Java heap.

does that mean it's similar to the NDK (per-processor architecture)?

 

[Informatix]

The NDK is what we use to produce the .so files. You don't have to bother with that. You don't need it.

 

[yttrium]

The NDK is what we use to produce the .so files. You don't have to bother with that. You don't need it.

I understand that, I'm just concerned that those .so files behind the scenes would be compiled for ARM-only, when my app also needs to run on x86 and Tegra devices.

 

[Informatix]

You have everything needed in the JAR file. You can open the JAR file with your zip utility and check the lib folder.

 

[yttrium]

That's not what I meant, but oh well, I guess I'll just have to test it on my multiple devices to confirm my suspicions.

 

[Informatix]

Did you try to unzip the jar file to look at the lib folder content? That is quicker than testing on different devices but of course testing is more sure.

 

[thedesolatesoul]

I understand that, I'm just concerned that those .so files behind the scenes would be compiled for ARM-only, when my app also needs to run on x86 and Tegra devices.

Tegra is ARM.
The three architectures Android supports (by default) are ARM, MIPS and x86.

From what I see in the jar file, it packs all architectures.

Remember 90% (or more) of devices are ARM.
A couple are x86 (I think orange san diego and some lenovo phones).
MIPS probably only a few exist mostly chinese manufactured. I dont know any.

 

[Informatix]

When I'm too lazy to explain, it's cool to see another guy doing it.

 

[yttrium]

Tegra is ARM.
The three architectures Android supports (by default) are ARM, MIPS and x86.

From what I see in the jar file, it packs all architectures.

Remember 90% (or more) of devices are ARM.
A couple are x86 (I think orange san diego and some lenovo phones).
MIPS probably only a few exist mostly chinese manufactured. I dont know any.

From what I've seen, native code written for other processors (like Snapdragon, Exynos, etc) doesn't run on Tegra devices, and likewise the other way around, even though both have an ARM architecture. Maybe I'm thinking of something else though.

As long as it packs the other architectures then it's fine. I'll look into it when I get some spare time.

 

[thedesolatesoul]

Are you thinking of THD or Tegra optimized / Snapdragon optimised (for e.g. https://play.google.com/store/apps/...ragon.app&psid=2&rdid=com.xiam.snapdragon.app)
Here the manufacturer is using non-standard code (thus as its not part of Android it is usually in C to be hidden) or drivers to access undocumented features of their own chips.

 

[yttrium]

Are you thinking of THD or Tegra optimized / Snapdragon optimised (for e.g. https://play.google.com/store/apps/...ragon.app&psid=2&rdid=com.xiam.snapdragon.app)
Here the manufacturer is using non-standard code (thus as its not part of Android it is usually in C to be hidden) or drivers to access undocumented features of their own chips.

I don't believe so. I'm not really sure where I read this, I must have misunderstood it because I can't find it anywhere online after some searching.