- Joined
- Jan 2, 2020
- Messages
- 1,414
I was actually thinking of trying to keep a android-only version temporary just to keep thingseasier and get a better overview and expriment, and if there's and findings it might be very easy to import them to the main branch.
I don't have the time to do it right now but it hopefully it already works good enough (and the most import reason is that I've been working on thigns for a long time but now I'm in a rush to get a product out and I think the quality will be technically high enough.
Some insiders insights.. for the ones who wants to know how to optimize for Android :
So anyways, I was wrong when I said that managed images was slow, they have no cost at all or at least it's not worth mentioning in big quantities even. The cost lays only in Flushing them because it uses the dreaded readpixels.
Changing readpixels into reinit-FBO or a shader would be more interesting than using Androids own flags and stadnard ways to preserve graphics. they are all slow and not even compatible with all devices. So those changes are a few things that I will experiment with. PBO will not give the boost either, not on a scale that makes it worth it.
I can also confirm that the 256x256 texture size is actually all about Android's implementation of readpixels.
The cost of reading goes up insanely on some devices around there. It's not linearly at all. So
This also means that if you want to read pixels of a canvas for some reason It's much better to first to draw what you want to read from a big canvas (it's practically zero cost even if its big) into a small canvas and read from that.
I don't have the time to do it right now but it hopefully it already works good enough (and the most import reason is that I've been working on thigns for a long time but now I'm in a rush to get a product out and I think the quality will be technically high enough.
Some insiders insights.. for the ones who wants to know how to optimize for Android :
So anyways, I was wrong when I said that managed images was slow, they have no cost at all or at least it's not worth mentioning in big quantities even. The cost lays only in Flushing them because it uses the dreaded readpixels.
Changing readpixels into reinit-FBO or a shader would be more interesting than using Androids own flags and stadnard ways to preserve graphics. they are all slow and not even compatible with all devices. So those changes are a few things that I will experiment with. PBO will not give the boost either, not on a scale that makes it worth it.
I can also confirm that the 256x256 texture size is actually all about Android's implementation of readpixels.
The cost of reading goes up insanely on some devices around there. It's not linearly at all. So
This also means that if you want to read pixels of a canvas for some reason It's much better to first to draw what you want to read from a big canvas (it's practically zero cost even if its big) into a small canvas and read from that.