I wonder if anyone can help me out with some advice. I'm just starting out with ProntoScript, and am trying to figure out the best design patterns for performance on my remote (a TSU9600). In particular, I'm trying to resolve the bottleneck of loading artwork for recently added content to my Kodi/Openelec box.

To help speed things up a little I've written a small nodejs app which runs on a Raspberry Pi 2 I have running on my network as a home automation server. This proxies image requests to Kodi and resizes the artwork down to a much smaller size (90px x 145px) before sending it back to the remote. Resized images are cached locally on the Pi so that they can be sent to the remote even quicker on future requests.

On the remote, my Kodi activity consists of a number of pages. Home, New Movies, New TV, Now Playing.

I have a ProntoScript on the activity level which requests the 10 most recently added movies and tv shows from the Kodi API. It then iterates through 10 widgets on the activity's "New Movies" page, setting each widget's image property to be the respective thumbnail.

var thumbnailWidget = widget("RECENT_10","NEW_MOVIES");
httpLib.showHTTPImage(imageUrl, thumbnailWidget);

The first problem I have is that despite having set these images on Activity load (when the remote is still on "Home", when I then navigate to the "New Movies" page, the UI is redrawn, and all the images are once again requested, which has a 2-3 second delay in the UI. Likewise if I then navigate to "New TV" and back, the UI is redrawn again.

So my questions are this;

1) Is there a way to pre-render the UI of a Page from the Activity script, and then have that UI be used when navigating to the page, rather than the default view being rendered and then udpated?

2) Is there a way to cache the images ahead of time, or after they are first loaded, to speed up subsequent screen updates? I figured that this might be handled by creating a hidden page where the images are loaded and then subsequently copied to the "New Movies" or "New TV" sections, but the problems I am having with 1) suggest that this may not resolve the problem. Is it better to perhaps encode the images as Base64 and then store them as variables in the global scope? If so, how do I then load the Base64 data back into the widgets? And will this be any faster than loading again from the web server?

Thanks in advance for any help with this.

You cannot pre-render UI from Activity Script. What you can do is to render the UI prior to showing the page by using the Page Script.

Note that whenever you change activities, all Script data is discarded. To save/restore across Activities, you can use 'Globals' which I discuss below.

There is a thread here where I discuss what is the difference between GUI.widget and CF.widget. The Activity and Page widget() functions are the equivalent of CF.widget. Note that GUI.widget is best used as a render target whereas the other functions CF, Activity, Page are best used to retrieve images from resources from your config. Also note that GUI.widget allows you to retrieve items with tags that may be on the System Page that are merged into view when your actual page is shown.

Look at the ProntoScript functions System.getGlobal and System.setGlobal in the Dev Guide. There is also a function/utility script uploaded by Rusty Fobe a few years back that will take JS arrays and convert it to a string (sounds like JSON - Javascript Object Notation).

[Link: files.remotecentral.com]

On order to use such functionality to capture your images as strings, you will need to have a look inside the Philips HTTP Library and intercept the string used to create the images prior to storing them into the widget. Possibly by modifying the Philips script. You Won't need to use Base64 encoding to save the image data. Beware that there is a limit to the amount of data you can save with System Globals. I seem to recall that it is something like 64KB per named Global.

Lyndel

Brilliant, plenty of food for thought and reading there. I'll go and have a look and see how I get on. Thanks Lyndel.