<br><br><div class="gmail_quote">On Thu, Jun 11, 2009 at 7:08 AM, Max Horn <span dir="ltr"><<a href="mailto:max@quendi.de">max@quendi.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>So far, I see no actual cons to using Graphics::PixelFormat -- I think LordHoto refuted all claims otherwise so far. Maybe we miss something, though -- then I'd like to hear concrete arguments, though ;).<br>
<br>
<br>
Bye,<br><font color="#888888">
Max
<br>
</font></blockquote></div><br><br>Sigh, I should have made a posting to the list right after the conversation LordHoto and I had on IRC wednesday night.<br>The cons to using Graphics::PixelFormat are<br>1) It is overkill -- it easily allows engines to specify a format that is completely impossible, by mistake<br>
2) It requires the engine to specify color order, meaning that a minor oversight on the part of the engine developer could result in it being unusable on all backends with a different color order.<br>3) Additionally, the wide range of color orders that the engine could potentially request necessitate a great deal of sanity checking on the part of engines that only support one.<br>
4) Setting up a Graphics::PixelFormat structure takes a minimum of 8 lines of code per structure. Engines like gob and groovie which convert from YUV have to set up a list of several, and the difference in coding required adds up over the course of three current and an unknown number of future supported engines.<br>
<br>The compromise that LordHoto and I came to on IRC is thus:<br>Engines use the colormode enum type, and pass a list of supported colormodes to initGraphics.<br>initGraphics gets the color order (RGBA, ABGR) from the backend, and converts the colormode enums.<br>
into Graphics::PixelFormat structures using a generic function provided for this purpose.<br>initGraphics queries the backend regarding format compatibility, and passes the first compatible format to the backend for initialization during the gfx transaction.<br>
initGraphics errors out if endGfxTransaction returns an error in setting up the screen with requested pixel format<br>engines query backend to determine the accepted pixel format<br>When loading graphical resources, engines call a generic color-order swapping function as necessary.<br>
<br>This way, engines get the simplicity of the enum type, but backends do not have to worry about dealing with any format but Graphics::PixelFormat.<br>I am working on the proof of concept for this, but if there are any complaints about this remaining, I will go ahead with one that uses Graphics::PixelFormat exclusively.<br>