Graphics Configuration

This section introduces the configuration items in the graphics backend.

compositor_buffer_size (1280x720)

Specifies the size of the system compositor surface. The size of the compositor surface is in effect the maximum meaningful resolution for applications on the STB. Any application rendering at a different resolution than the compositor surface will be scaled to match it. Video resolution is not affected by this limitation. If not set explicitly, the size in parentheses will be used instead. Read more about compositing here.

An example boot image configuration file to set this parameter would look like this:

  kreatv-option-graphics::compositor_buffer_size=720x576

memory_size

Specifies the total amount of graphics memory, in KiB, available to the platform and applications. This is the size of the memory partition used for graphics. The actual number used should consider all necessary graphics surfaces, as well as possible pixmaps in the different applications which may also consume graphics memory. If not set explicitly, the minimal required value for basic graphics will be chosen. The minimal value depends on many factors and is usually between 35 MiB and 70 MiB.

An example boot image configuration file to set this parameter would look like this:

  kreatv-option-graphics::memory_size=74640

It is not a trivial task to manually calculate the amount of graphics memory that the installed applications require. The profiler service shall be used to view and fine tune the graphics memory consumption. Here you can read a quick guide on memory size calculation.

How to calculate the graphics memory size

The idea is to open all portal pages and try to load the system as much as possible. For instance, it usually makes sense to navigate in the EPG by quickly pressing nagivation keys or a remote control. The faster the EPG receives navigation commands, the more graphics memory the system uses to perform animations on the screen. Another good portal section might be the VOD store because it usually contains a lot of posters that are animated during navigation.

If a secondary application is installed (e.g. YouTube), it is especially important to launch it and navigate in a similar way.

The profiler service monitors graphics memory consumption. Once your navigation tests are executed, you can get the peak graphics memory consumption by running the following command in the STB console:

  toish profiler GetSample 1 var.graphics.memory.peak

The output will look like below (measured in bytes):

  var.graphics.memory.peak: 63692800

Alternatively, you may retrieve the peak graphics memory usage from the portal code:

  var profiler = toi.profilerService;
  var session;
  try {
    session = profiler.createProfilingSession("WebKit Portal");
    var prop = profiler.VAR_PROPERTY_GRAPHICS_MEMORY_PEAK;
    profiler.addMonitoredProperty(session, prop, 0);
    profiler.startProfiling(session);

    var peakMemory = profiler.getSample(session, prop);
    console.log("Peak graphics memory: " + peakMemory.value + " bytes");
  }
  catch (e) {
    console.error(e);
  }

  // stop and release the session at some later point when done
  try {
    profiler.releaseProfilingSession(session);
  }
  catch (e) {
    console.error(e);
  }

It is recommended to reserve some extra graphics memory. Reserving 20% additional memory is usually reasonable. In the above example, the total amount of graphics memory that should be set is equal to 63692800 * 1.2 / 1024 = 74,640 KiB.