Base module for static asset caches.

This module is not intended to be used directly. To access items in the static cache, refer to the modules for the type of data you are interested in.

Some of the Cache support modules have moved

Overview

Static assets such as fonts, images and more tend to be relatively large compared to other data. These assets are often used across multiple scenes and may need to be shared with multiple drivers.

These assets also tend to have a significant load cost. Fonts need to be rendered. Images interpreted into their final binary form, etc.

Goals

Given this situation, the Cache module has multiple goals.

• Reuse - assets used by multiple scenes should only be stored in memory once
• Load Time- loading cost should only be paid once
• Copy time - assets are stored in ETS, so they don't need to be copied as they are used
• Pub/Sub - Consumers of static assets (drivers...) should be notified when an asset is loaded or changed. They should not poll the system.
• Security - Static assets can become an attack vector. Helper modules are provided to assist in verifying these files.

Scope

When an asset is loaded into the cache, it is assigned a scope. The scope is used to determine how long to hold the asset in memory before it is unloaded. Scope is either the atom :global, or a pid.

The typical flow is that a scene will load an asset into the cache. A scope is automatically defined that tracks the asset against the pid of the scene that loaded it. When the scene is closed, the scope becomes empty and the asset is unloaded.

If, while that scene is loaded, another scene (or any process...) attempts to load the same asset into the cache, a second scope is added and the duplicate load is skipped. When the first scene closes, the asset stays in memory as long as the second scope remains valid.

When a scene closes, it's scope stays valid for a short time in order to give the next scene a chance to load its assets (or claim a scope) and possibly re-use the already loaded assets.

This is also useful in the event of a scene crashing and being restarted. The delay in unloading the scope means that the replacement scene will use already loaded assets instead of loading the same files again for no real benefit.

When you load assets you can alternately provide your own scope instead of taking the default, which is your processes pid. If you provide :global, then the asset will stay in memory until you explicitly release it.

Keys

At its simplest, accessing the cache is a key-value store. When inserting assets via the main Cache module, you can supply any term you want as the key. However, in most cases this is not recommended.

The key for an item in the cache should almost always be a SHA hash of the item itself.

Why? Read below...

The main exception is dynamic assets, such as video frames coming from a camera.

Security

A lesson learned the hard way is that static assets (fonts, images, etc.) that your app loads out of storage can easily become attack vectors.

These formats are complicated! There is no guarantee (on any system) that a malformed asset will not cause an error in the C code that interprets it. Again - these are complicated and the renderers need to be fast...

The solution is to compute a SHA hash of these files during build-time of your and to store the result in your applications code itself. Then during run time, you compare then pre-computed hash against the run-time of the asset being loaded.

Please take advantage of the helper modules Cache.File, Cache.Term, and Cache.Hash to do this for you. These modules load files and insert them into the cache while checking a precomputed hash.

These scheme is much stronger when the application code itself is also signed and verified, but that is an exercise for the packaging tools.

Full Example:

defmodule MyApp.MyScene do
  use Scenic.Scene
  import Scenic.Primitives

  # build the path to the static asset file (compile time)
  @asset_path :code.priv_dir(:my_app)
  |> Path.join("/static/images/asset.jpg")

  # pre-compute the hash (compile time)
  @asset_hash Scenic.Cache.Hash.file!( @asset_path, :sha )

  # build a graph that uses the asset (compile time)
  @graph Scenic.Graph.build()
  |> rect( {100, 100}, fill: {:image, @asset_hash} )


  def init( _, _ ) do
    # load the asset into the cache (run time)
    Scenic.Cache.Static.Texture.load(@asset_path, @asset_hash)

    {:ok, :some_state, push: @graph}
  end

end

When assets are loaded this way, the @asset_hash term is also used as the key in the cache. This has the additional benefit of allowing you to pre-compute the graph itself, using the correct keys for the correct assets.

Pub/Sub

Drivers (or any process...) listen to the Cache via a simple pub/sub api.

Because the graph, may be computed during compile time and pushed at some other time than the assets are loaded, the drivers need to know when the assets become available.

Whenever any asset is loaded into the cache, messages are sent to any subscribing processes along with the affected keys. This allows them to react in a loosely-coupled way to how the assets are managed in your scene.