One other thought, I believe that scaling with the texturemanger is slower than using DrawScaledObject as least that Is what I recall reading recently on here. So again if you are doing a lot of scaling then perhaps that too will contribute to performance issues
My Channels: 2D API Framework Presentation: https://owner.roku.com/add/2M9LCVC Updated: 11-11-2015 - Completed Keyboard interface The Joel Channel ( Final Beta )
"greno" wrote: However, waiting for the request took 11 seconds over a LAN
Eleven seconds over a LAN is pretty extreme and indicates there is something else going on and you aren't at the point of dealing with the Roku's speed limitations yet. The thing is, if you intend to take pics fresh out of any current camera or phone, you are going to be processing a lot of pixels you'll never see, to get it down to a size where the Roku can deal with it. The major time issue to me seems to be the initial size of the picture, once it's in the Roku, theres plenty of time to deal with it - texturemanager or not, async or not. Thats one good thing about a slide show - theres lot's of time with a picture sitting on the screen, where you can do stuff in the background without it being noticed, because nothings moving.
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.
"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
Maybe I'm missing something since I'm just giving this thread a quick read but have you tried downloading the image to tmp with roURLTransfer, then using roImageMetadata to read the EXIF, then use roTextureManager to resize the image to something 2048x2048 or smaller, then use the resulting bitmap with DrawRotatedObject if it needs to be rotated?