At a previous meeting we decided to split "Type 2" Display Sharing and eventually considered it to be a subcategory of Surface Sharing.

It describes a kind of "Virtual Display" setup that is frequently mentioned in some programming environments. 

Virtual Display

Virtual Display vs. Surface sharing:

This distinction is not 100% precise, and there are likely systems out there that could be considered somewhat hybrid in nature. Here is how we consider Surface & Display sharing different:

It is clear that there may be some other variations when it becomes difficult to fully differentiate between for example Surface Sharing and Virtual Display.  In such cases we would recommend calling it Surface Sharing.  In the end the result matters more than the definition, of course.


Specific implementations

1. Weston compositor virtual-display and gst-recorder plugin

  • Renesas Weston compositor virtual-display and gst-recorder plugin
    • virtual-display allows the creation of a composited display window the correct size which can then be remoted
    • gst-recorder GStreamer plugin in Weston Compositor encodes the virtual display using H.264 and transmits. Receiver uses GStreamer to receive and decode the stream, which can then be composited as required.
    • Pros:
      • No modification required to Weston on receiver side.
      • If layer control is required the decoded stream can be transformed as required on receiver side in gfx framework of your choosing.
      • Video encoding minimises network data and bandwidth
      • Virtual display means display size can be made only as large as needed.
      • Technology has multiple applications, e.g. has been used in Waltham implementation for gfx data transfer.
    • Cons:
      • Delay of about 2-3 vsync to encode, transmit, receive, decode and composite the stream.
      • Large display containing a lot of animated objects will impact network bandwidth
    • R-Car M3 PoC in AGL demonstrator. Open source: links TBA
      • Two M3 ECUs. Navigation and mapview app encodes mapview image using gst-recorder and transfers via ethernet (udp). Receiver mapview image, decodes the data and displays moving map image between dials of cluster display.
    • See the slides presented at the ALS 2018 talk "Remote Access and Output Sharing Between Multiple ECUs for Automotive"

2. Android ScreenCast over network to other OSs

  • Renesas ported ScreenCast for virtual display remoting from Android
  • A virtual display screen buffer is encoded, transmitted over the network, then decoded by the receiving OS. In this way it uses some similar technology from the Weston remote implementation above.
  • Pros:
    • Widely supported transmission standard means wide variety of OSs and applications can be used on the receiving end.
    • If layer control is required the decoded stream can be transformed as required on receiver side in gfx framework of your choosing.
    • Video encoding minimises network data and bandwidth
    • Virtual display means display size can be made only as large as needed.
  • Cons:
    • Large display containing a lot of animated objects will impact network bandwidth