[Mesa-dev] [PATCH 0/8] sRGB fixes

[Adam Jackson]

On Thu, 2012-10-25 at 11:33 -0700, Ian Romanick wrote:
> On 10/25/2012 07:37 AM, Adam Jackson wrote:
> > I don't see why that's true.  You don't get sRGB rendering until you've
> > called glEnable(GL_FRAMEBUFFER_SRGB).  Just flag all your fbconfigs as
> > sRGB-capable.  Older libGL looks like it's smart enough to ignore
> > unknown attribs, and current libGL doesn't look at the sRGB attrib in
> > fbconfig matching.
> 
> There's an attribute on the fbconfig that says, "You can enable sRGB 
> encoding when rendering to drawables with this config."  We'll only set 
> this flag on drawables with RGBA8888 or RGB888.  We won't set it on 
> 5-6-5 or 10-10-10-2.
> 
> By default the sRGB enable is off.  This means that giving an app an 
> sRGB fbconfig when they didn't ask for one is okay.  It may, however, 
> hide bugs in apps that should have asked for an sRGB fbconfig but didn't.

I guess, though I normally don't think of "provoke all possible
application bugs" as one of Mesa's explicit goals.

But if we did want to tripwire that, it seems more like something I'd
build into ARB_debug than something I'd enforce through the matrix of
fbconfigs.  And if you're not setting sRGBCapable on non-8bpc configs
then you should be able to provoke that just by changing xserver's root
window depth (though, I admit, not if the app insists on 8bpc fbconfig).

Shrug.  Don't have a terribly strong opinion, if I had to give one I'd
say exploding the list of visuals even further feels a bit silly.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20121025/3ab85f39/attachment.pgp>