I have recieved and reviewed the discussion in this thread, and I'm a bit worried by the results:<br>One vote (Sven) for the old bitformat (8, 555, 565, 888) style of format specification<br>One vote (Eugene) for the engine requesting only a bitdepth, not a full format<br>
Two votes (Johannes and Max) for the engine requesting a (list of) fully formed Graphics::PixelFormat object(s).<br>One vote (Myself) for using an enumerated list <br>Three people (Marcus, Joost, Oystein) contributing useful information about backend concerns, but no recommendations of their own<br>
<br>Nothing resembling a consensus, and very little discussion on the pros and cons of each method.<br><br>So, I'm going to list the pros and cons (as I see them) for each format:<br><br><ul><li>Old bitformat:</li><ul>
<li>Pros:</li></ul><ul><ul><li>Already defined and implemented</li><li>Values presented in a very readable and understandable format<br></li><li>Requires minimum of sanity checking by backends</li><li>Requires minimum of sanity checking by engines</li>
</ul><li>Cons:</li><ul><li>Requires extra work for backends wanting to add support for a format not currently defined</li><li>Requires extra conversions to/from a format that can be understood by video interface</li><li>Viewed as outdated and "evil" by some menbers of the community</li>
</ul><li>Neutral/dependant:</li><ul><li>Backend responsible for specifying color order<br></li></ul></ul><li>Bitdepth only</li><ul><li>Pros:</li><ul><li>Already defined</li><li>Values presented in a very readable and understandable format<br>
</li><li>Minimum of sanity checking necessary for backend</li></ul><li>Cons</li><ul><li>Disallows possibility of multiple formats in same bitdepth (ARGB1555/RGB555/RGB565/RGBA444)</li><li>Requires all engines with higher than 256 color modes to fully understand Graphics::PixelFormat values<br>
</li><li>Requires all engines with higher than 256 color modes to support color format conversions to match backend<br></li><li>Requires extra conversions to/from a format that can be understood by  video interface</li></ul>
<li>Neutral/dependant:</li><ul><li>Backend entirely responsible for specifying color format</li></ul></ul><li>Graphics::PixelFormat</li><ul><li>Pros:</li><ul><li>Already defined and implemented</li><li>Allows great flexibility in negotiation of color mode between engine and backend</li>
<li>No extra conversions necessary once format is agreed upon</li></ul><li>Cons:</li><ul><li>Complicated for engine to produce a list of supported formats</li><li>Requires backend developers to create and maintain a comprehensive list of supported formats or perform extensive checks to determine compatibility.<br>
</li><li>Requires engine to fully understand and work with Graphics::PixelFormat object</li></ul><li>Neutral/dependant:</li><ul><li>Engine is primarily responsible for determining color format.<br></li></ul></ul><li>Enum type (colormode and colororder fields)</li>
<ul><li>Pros:</li><ul><li>Allows great flexibility in negotiation of color mode between engine and backend</li><li>Values presented in a very readable and understandable format</li><li>Requires minimum of sanity checking by backends</li>
<li>Requires minimum of sanity checking by engines</li></ul><li>Cons:</li><ul><li>Slightly complicated for engine to produce list of supported formats.</li><li>Requires extra conversions to/from a format that can be understood by video interface.</li>
</ul><li>Neutral/dependant:</li><ul><li>Engine is primarily responsible for determining color format.</li></ul></ul><li>Enum type (colormode only)</li><ul><li>Pros:</li><ul><li>Values presented in a very readable and understandable format</li>
<li>Requires minimum of sanity checking by backends</li><li>Requires minimum of sanity checking by engines</li></ul><li>Cons:</li><ul><li>Requires extra conversions to/from a format that can be understood by video interface.</li>
</ul><li>Neutral/dependant:</li><ul><li>Backend responsible for specifying color order</li></ul></ul><li>New type (not yet defined)</li><ul><li>Pros:</li><ul><li>Can be designed specifically for this task</li></ul><li>Cons:</li>
<ul><li>May require significant effort to implement</li></ul></ul></ul>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.<br>