Prevent unnecessary screen flicker on dupe content

[ryanckulp]

our web server takes care to not waste compute on duplicate screen/render content. we achieve this by fetching {{ merge variable }} data, then comparing it to the last fetched variable data, and escaping the image generation process if there is no difference.

but there are exceptions to this strategy. in cases like our Image Display plugin the content will always be the same, so the web server will always respond with an image_url when the device pings api/display.

goal

1. firmware determines if fetched content is different from the content currenty on the screen
2. if content is the same, don't re-render (prevent screen flicker)

this is especially helpful if one's device is merely showing a few (mostly) static pieces of content, for example their daily schedule or upcoming movies, which won't change very often. in these cases the device should only visibly update a few times per day, even if the refresh rate is set to 5 mins (e.g.).

thoughts

• comparing the absolute image URL won't work due to the nature of our signed / hashed S3 urls which change every few moments
• could we inspect some BMP headers etc?

[ronakjain90]

Our file name would still be unique. So storing the currently rendered filename can be a good strategy. Thoughts @ryanckulp

[ryanckulp]

i like that.

@MichaelXlivnenko how about adding to our api/display response:

{
 # ... 
  image_name: "plugin-name-xxx"
}

where xxx is a timestamp. firmware then stores last_rendered_image_name or similar and diffs against current response image_name.

[levsha]

What do you think about using already existing http headers? For example If-Modified-Since in the http request or Last-Modified in the HTTP response

[derobert]

What do you think about using already existing http headers?

To identify duplicate content (in this case, strongly duplicate — same bits), that'd be ETag and If-None-Match.

S3 is likely already producing the ETag header for you, so this might just be adding the If-None-Match with the previous image's ETag to the firmware and then handling the 304 response.

[MichaelXlivnenko]

i like that.

@MichaelXlivnenko how about adding to our api/display response:

{
 # ... 
  image_name: "plugin-name-xxx"
}

where xxx is a timestamp. firmware then stores last_rendered_image_name or similar and diffs against current response image_name.

I think it's enough for us to store just the name of the image if it's unique

[ryanckulp]

cool, @ronakjain90 in Core can you refactor Device::Render to return a screen object vs its attached image absolute URL so we have access to filename() attr?

got us started here: https://github.com/usetrmnl/core/pull/268

[MichaelXlivnenko]

In version 1.3.2 added filename saving

[ryanckulp]

thanks, still working on adding "image_name" but will be in Display response soon