I had the same problem when loading as ARGB_565. Use inDither to get
rid of very obvious stair-stepping. I would say I could spot a 16-bit
image, especially with a lot of reds, on a less red screen (Xoom and
Acer Iconia Tab A500) while the Galaxy Tab 7" is a whole splotch of
red. However with inDit
> On some devices that is going to be way over budget.
The 8mp example is the max case. I don't expect low-end devices to
have an 8mp camera. So let me try again, about 64MB of extra space in
native on a phone that has 512MB of RAM, is that reasonable? I am just
trying to find a right balance here
On Wed, Jun 8, 2011 at 3:17 PM, webmonkey wrote:
> > No, as I said, your app will eventually be silently killed.
> OK, but not if you are a foreground app, wouldn't be very silent ;-)
>
It is silent as far as you are concerned -- no warning, no way to recover,
just *poof*.
> I am talking sane
> No, as I said, your app will eventually be silently killed.
OK, but not if you are a foreground app, wouldn't be very silent ;-)
> Pretty universally people coming from a desktop environment have a very
> different definition of "reasonable amount of memory" than is actually sane
> for a mobile
On Wed, Jun 8, 2011 at 1:15 PM, webmonkey wrote:
> How does the native heap actually tell you, will malloc return NULL if
> it cannot reserve enough space?
>
No, as I said, your app will eventually be silently killed.
> And if you are a foreground app, you won't get in trouble will you
> (unle
Yeah, but it'll do. :-)
The quality of the cameras on phones and tablets is not that great anyway.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from
That works but I don't consider 16-bit to be "full-resolution", color
fidelity is just as important.
On Jun 8, 10:25 pm, Streets Of Boston wrote:
> I guess it's playing nice to other background apps. Even a foreground app
> can't gobble up all the memory and starve the background apps.
>
> I figu
I guess it's playing nice to other background apps. Even a foreground app
can't gobble up all the memory and starve the background apps.
I figured out a way to edit 9MPixel images 16-bit (i.e. 18MByte of data). It
makes you program quite carefully when using the left over 6Mbyte of memory,
but
How does the native heap actually tell you, will malloc return NULL if
it cannot reserve enough space?
And if you are a foreground app, you won't get in trouble will you
(unless you use insane amounts of it) I can understand that a
background app should not use more native memory than the limit.
It is kind of ridiculous that you cannot just load a bitmap in full
quality the size of the phone's camera capability, let alone edit it.
Then you have to explain to users that you can't because you can only
use 16/24/32 MB when their phones have 512MB.
As open and powerful as Android is, I never
I wrote an image editor app that claims to deal with full-resolution of the
images.
However, there is a limit due to the 'issues' you found (limit memory).
I got around it (at least, i haven't seen many stack-traces/error-logs sent
my way) by doing this:
- Limit the resolution. On 1st gen de
11 matches
Mail list logo
