My problem is I'm dealing with two devices with limited ability to do image manipulation. For background, this is for my Android app "Juice for Roku", which allows users to send media from their phone to the Roku without the need of it going to a server somewhere. If I do the manipulation on the phone, there is a very good chance of the app crashing with an out of memory condition (even on newer phones). That's why I wanted to do it on the Roku if possible.
On almost all Samsung phones (and some other manufacturers like LG) when they capture an image, they always store it in a landscape format. So if the photo is taken as a portrait, it still saves in landscape mode but adds an orientation angle to the image EXIF, and expects the displaying device to show it correctly. My users complain about the images showing up sideways. That's why I was hoping Roku would support EXIF so I wouldn't have to do this manipulation.
-Gregg
"NewManLiving" wrote:
I don't know what the slideshow is using. If not the texturemanager then whatever it is I would like to have access to it. The thing with the texturemanager in my experience is that 'generally' the more you asynchronously request during one transaction, is faster than polling for one image to return or using the synchronous method. It does have some type of LRU ( at least it appears that way ) so the next time is faster. You have to tweak it yourself. If you can, it probably would be better to reduce the file size to something smaller. I convert to jpg whenever possible since (most of the time) it is a much smaller file size than png. Or if it does have transparency in it I may create a layer with the background underneath (if the background is static) and then convert to jpg. Squirreltown has far more experience with larger bitmaps and the texturemanager. Perhaps he can offer further insight
