[Scummvm-devel] Bitdepth/pixel format API concerns

[J Northup]

I have recieved and reviewed the discussion in this thread, and I'm a bit
worried by the results:
One vote (Sven) for the old bitformat (8, 555, 565, 888) style of format
specification
One vote (Eugene) for the engine requesting only a bitdepth, not a full
format
Two votes (Johannes and Max) for the engine requesting a (list of) fully
formed Graphics::PixelFormat object(s).
One vote (Myself) for using an enumerated list
Three people (Marcus, Joost, Oystein) contributing useful information about
backend concerns, but no recommendations of their own

Nothing resembling a consensus, and very little discussion on the pros and
cons of each method.

So, I'm going to list the pros and cons (as I see them) for each format:


   - Old bitformat:
      - Pros:
   - Already defined and implemented
         - Values presented in a very readable and understandable format
         - Requires minimum of sanity checking by backends
         - Requires minimum of sanity checking by engines
      - Cons:
         - Requires extra work for backends wanting to add support for a
         format not currently defined
         - Requires extra conversions to/from a format that can be
         understood by video interface
         - Viewed as outdated and "evil" by some menbers of the community
      - Neutral/dependant:
         - Backend responsible for specifying color order
         - Bitdepth only
      - Pros:
         - Already defined
         - Values presented in a very readable and understandable format
         - Minimum of sanity checking necessary for backend
      - Cons
         - Disallows possibility of multiple formats in same bitdepth
         (ARGB1555/RGB555/RGB565/RGBA444)
         - Requires all engines with higher than 256 color modes to fully
         understand Graphics::PixelFormat values
         - Requires all engines with higher than 256 color modes to support
         color format conversions to match backend
         - Requires extra conversions to/from a format that can be
         understood by video interface
      - Neutral/dependant:
         - Backend entirely responsible for specifying color format
      - Graphics::PixelFormat
      - Pros:
         - Already defined and implemented
         - Allows great flexibility in negotiation of color mode between
         engine and backend
         - No extra conversions necessary once format is agreed upon
      - Cons:
         - Complicated for engine to produce a list of supported formats
         - Requires backend developers to create and maintain a
         comprehensive list of supported formats or perform extensive checks to
         determine compatibility.
         - Requires engine to fully understand and work with
         Graphics::PixelFormat object
      - Neutral/dependant:
         - Engine is primarily responsible for determining color format.
         - Enum type (colormode and colororder fields)
      - Pros:
         - Allows great flexibility in negotiation of color mode between
         engine and backend
         - Values presented in a very readable and understandable format
         - Requires minimum of sanity checking by backends
         - Requires minimum of sanity checking by engines
      - Cons:
         - Slightly complicated for engine to produce list of supported
         formats.
         - Requires extra conversions to/from a format that can be
         understood by video interface.
      - Neutral/dependant:
         - Engine is primarily responsible for determining color format.
      - Enum type (colormode only)
      - Pros:
         - Values presented in a very readable and understandable format
         - Requires minimum of sanity checking by backends
         - Requires minimum of sanity checking by engines
      - Cons:
         - Requires extra conversions to/from a format that can be
         understood by video interface.
      - Neutral/dependant:
         - Backend responsible for specifying color order
      - New type (not yet defined)
      - Pros:
         - Can be designed specifically for this task
      - Cons:
         - May require significant effort to implement

Now, if I take Eugene's recommendation (from IRC) that color order passed
from engine to backend is always RGBA, then removing the ability from the
engines to specify their own order is actually a plus, as it shields from
potential future developer error. But, I don't know if that idea is
universally agreed upon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090611/4af0aa4b/attachment.html>