video_arch

Architecture of ARAnyM video subsystem

Previous architecture, up to 0.9.5

Till version 0.9.5, video rendering was done done in a single SDL_Surface (framebuffer if you prefer). Depending on the active state of ARAnym (videl rendering, nfvdi rendering, booting, gui enabled, etc...), great care was needed to be sure everything was drawn in the correct order, and not dirty parts of screen that should not. GUI can not be used when OpenGL is enabled (because drawing GUI is done in a different thread), and the host screen class hold a mutex to prevent simultaneous drawing to the screen surface. Add to that that on MacOSX, accessing the screen surface is slow (the current screen datas must be copied from vram to ram, modified there, and copied back to vram) when doing software rendering.

In both cases, either Videl is rendered, or NFVDI is rendered, then GUI is rendered on top of it.

Software rendering

  Videl rendering
  (with or without zoom)   ->   /--------------------\
                                |                    |
  NFVDI rendering          ->   | SDL screen surface |
                                |                    |
  GUI rendering            ->   \--------------------/

OpenGL rendering

  Videl rendering            /----------------\
  (with or without zoom) ->  |                |      /--------------------\
                             |                |      |                    |
  NFVDI rendering            | OpenGL texture | ->   |                    |
  (software)             ->  |                |      |                    |
                             \----------------/      | SDL screen surface |
  NFVDI rendering                                    |                    |
  (OpenGL)               ->   OpenGL commands   ->   |                    |
                                                     |                    |
  No GUI rendering                                   \--------------------/
  (different drawing thread)

Current architecture, from 0.9.6

The planned rework is to have each subsystem renders in its own surface (or OpenGL texture when OpenGL is enabled), and then the host screen class will do the compositing, i.e. pickup what needs to be drawn on the screen surface, and render all at once, no more mutex needed, no slow rendering on MacOSX.

It also allow switching between Videl and NFVDI screens on the fly. More surfaces can also be added, like drawing a logo till the Videl surface is ready.

Software rendering

                               /-------------\
  Logo                     ->  | SDL surface | -\
                               \-------------/  |
  Videl rendering              /-------------\  |                  /--------------------\
  (with or without zoom)   ->  | SDL surface | -+                  |                    |
                               \-------------/  |                  |                    |
                               /-------------\  |                  |                    |
  NFVDI rendering          ->  | SDL surface | -+-> host screen -> | SDL screen surface |
                               \-------------/  |   composition    |                    |
                               /-------------\  |                  |                    |
  GUI rendering            ->  | SDL surface | -/                  |                    |
                               \-------------/                     \--------------------/

OpenGL rendering

                          /-------------\    /----------------\
  Logo                 -> | SDL surface | -> | OpenGL texture | -\
                          \-------------/    \----------------/  |
  Videl rendering         /-------------\    /----------------\  |                  /--------------------\
  (OpenGL can zoom)    -> | SDL surface | -> | OpenGL texture | -+                  |                    |
                          \-------------/    \----------------/  |                  |                    |
                          /-------------\    /----------------\  |                  |                    |
  NFVDI rendering      -> | SDL surface | -> | OpenGL texture | -+-> host screen -> | SDL screen surface |
  (software rendering)    \-------------/    \----------------/  |   composition    |                    |
                          /-------------\    /----------------\  |                  |                    |
  GUI rendering        -> | SDL surface | -> | OpenGL texture | -/                  |                    |
                          \-------------/    \----------------/                     \--------------------/

As you can see, there are two problems to fix there:

• NFVDI can not use OpenGL to render, because it will mess with host screen compositing, so more work is needed.
• GUI rendering must not use a thread for rendering. This is done.

Future work

Once we have both software and OpenGL renderers working, there will be a last step to do. Being able to use hardware accelerated OpenGL rendering in different parts of ARAnyM. It means, having the compositing layer, the nfvdi OpenGL backend, and maybe later Atari applications make use of it without any problems.