bitdepth/pixelformat pros and cons

I have recieved and reviewed the discussion in the bitdepth/pixelformat mailing list thread that I started, 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.