makeImageRequst on a 4.0 device

Now that we have a sample 4.0 device to play with, I decided to see how the new graphics/bitmap handling will affect my widget.  It appears that I am going to need to make some changes to how I handle receiving bitmaps through the makeImageRequest function.

On existing devices I check that the data is actually a bitmap resource.  If it is, I save it to a class variable (bitmap) which I then display on the screen with the next onUpdate.  What I am seeing is the data does not pass the instanceof check for BitmapResource on the 4.0 device.  Below is my call back method being used.

function onReceiveImage(responseCode, data) {
    System.println("view fctn recieveimg");
	if(responseCode==200) {
		if(data instanceof Ui.BitmapResource) {
			System.println("IMAGE OK");
			bitmap = data;
			Ui.requestUpdate();
		} else {
			System.println("IMAGE NOT OK");
		}
	} else {
		data = null;
		System.println("imgstatus="+DisplayError);
		Ui.requestUpdate();
	}
}
 

On the 3.x and below devices, the Image Ok will print and the bitmap will display.  On the 4.0 sample device, I get Image Not Ok, thus the bitmap is not set.  The makeImageRequest documentation says that the callback should expect two inputs and the data should be a BitmapResource or null.  

responseCallback as Method(responseCode as Number, data as BitmapResource or Null)

My question is because of the new graphics pool, do I need to wrap the data in the new createBufferedBitmap method to save the downloaded resource for display?

  • What happens if you just skip the instanceof check and assume it's good (as a test)?  Just check for null.  The graphics pool should be involved with 4.0, so looks like a it could be a bug with that and makeImageRequest.

  • Jim, I am currently working on just that so see what happens.  I do the instanceof check when the data comes in and also as part of the display to make sure I have an image before trying to display something that could crash.  For troubleshooting, I don't need as many checks.  I did not figure many developers have played around with make image request on the 4.0 devices yet and it is not quite working as I expected, I figured there is something at play and worth starting a discussion. Grin

  • Very interesting. We've tested image requests on 4.0 products already (which, incidentally, have worked as expected), but I don't think we've tested this particular case. I'll follow up and may move this to bug reports.

  • Thanks Brandon.  I was able to do some testing by switching my instanceof check to a !=null.  I see the "data" received is being put into the device memory as a graphics pool reference object that my bitmap variable is referencing.  I also was able to change my onUpdate code to check the bitmap variable is != null and now the image will be displayed.

    What I learned is any check for BitmapResource does not work on 4.0 devices in the same why as on 3.2 and below.  

  • When running on a 4.x device, you should actually expect to get a ResourceReference or null. The BitmpaResource you'd normally get is stored in the graphics pool for you already.

    I'm making a note that the API docs and the API signature for the callback is incorrect here.

  • Travis, When looking at the memory viewer I was able to come to that conclusion and finally got everything working.  So the note will be helpful.

    Now that question is how big is the graphics pool, and how do I keep track of the available image space if I want to download 2-3 images?

  • We've built the graphics pool in a way where you hopefully won't need to worry about the available space. Of course, there is a limit, but it should behave as though there's no limit because the system will dynamically manage resources behind the scenes. (I'm paraphrasing what the Core Topics docs state.)

  • Brandon,  Now that I figured out what was going on.  I like how the graphics pool is working.  I was able to download 3 images on the "upcoming wearable" with each image ~320k and display my animation.  The peak memory usage was only 36k.  That is quite an improvement over older devices having to tweak image parameters for different devices due to memory limits.

  • After doing some playing around, it appears that the following adjustment to my code works on 1.x-4.x devices, or at least it does in the simulator.

    function onReceiveImage(responseCode, data) {
        System.println("view fctn recieveimg");
    	if(responseCode==200) {
    		if (data != null) {
    			System.println("IMAGE OK");
    			bitmap = data;
    			Ui.requestUpdate();
    		} else {
    			System.println("IMAGE NOT OK");
    		}
    	} else {
    		data = null;
    		System.println("imgstatus="+DisplayError);
    		Ui.requestUpdate();
    	}
    }

  • If you have something like a WF with a bunch of custom fonts and/or bitmaps, you can really see the impact of the 4.x graphics pool on app memory.  Yes, it's cool!