Currently when using the software rendering interface of the embedder API, flutter will use RGBA8888 or BGRA8888 as the pixel format for the framebuffers (depending on CPU endianess). The proposal is to allow other formats as well, e.g. RGB565.

There are multiple reasons why (for example) RGB565 is cool to have:

• some displays / display drivers only support RGB565. For example many linux fbdev displays.
• right now, outputting to such devices requires manual conversion to RGB565, which is slow.
• especially because devices without a GPU are probably limited in other aspects as well
• if you have a embedded device that does support outputting RGBA or BGRA, you might still want to use RGB565 for performance reasons.
• embedded devices are typically limited in memory bandwidth, so the less memory you have to access the better. (using RGB565 is a common hack to get some more FPS out of constrained hardware)

We can also maybe improve some sw rendering docs, for example nowhere in the embedder.h file is documented what pixel format is used by default

Proposal

Expanding the API to allow other pixel formats isn't that trivial because the structs that need to be expanded aren't versioned. So I think we should introduce a new type of backing store called kFlutterBackingStoreTypeSoftware2 and deprecate the old one.

new backing store type could look like this:

typedef struct {
  size_t struct_size;
  const void* allocation;
  size_t row_bytes;
  size_t height;
  FlutterPixelFormat pixel_format;
  void* user_data;
  VoidCallback destruction_callback;
} FlutterSoftwareBackingStore2;

and for pixel format, I'd just support anything that is supported by skia. Even grayscale may be useful for e-paper displays for example.

typedef enum {
  kAlpha8,
  kRGB565,
  kARGB4444,
  // ...
} FlutterPixelFormat;