Bug 6155 – DumpRenderTree should set a consistent color profile while running

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Eric Seidel (no email)]

DumpRenderTree should set a consistant color profile while running

Right now any content which is drawn color matched (images which contain an embedded color profile, 
certain SVG content) will cause DumpRenderTree pixel tests to produce inconsitent results on differnet 
machines.

I haven't been able to find any particularlly elegent solution to this problem.  But I have been able to find a 
solution.  The attached patch makes DumpRenderTree set the system color profile to "Generic RGB" on 
launch (when --pixel is enabled) and then resets it to whatever the user had set on process exit.  There 
may yet be a more elegent (per process!) solution.

[Eric Seidel (no email)]

Created attachment 5167 [details]
Proposed patch.

This patch also contains changes to make DumpRenderTree change it's WebKit size
while in the SVG W3C tests directory (which require being run at a specific
size).	You can ignore those if you wish.

[Eric Seidel (no email)]

Comment on attachment 5167 [details]
Proposed patch.

You can ignore the (small) SVG related changes in this bug.  Darin and mjs will
likely have opinions on this patch.  I'm certainly open to other options, if we
find them.

[Darin Adler]

Comment on attachment 5167 [details]
Proposed patch.

Since this is a plain C file, functions with no parameters need to be declared
with (void) rather than ().

The fprintf call needs a "\n" at the end, otherwise it will be smushed together
with the next line. Also, no need to put two spaces after those periods. These
messages are so long I think the sentences should go on separate lines.

It's amazing, I'd never heard of %i before, but it turns out to be a synonym
for %d.

No need for the redundant & in the atexit call.

One of the fprintf calls is missing a space after the "stderr,".

The changes to width and height are separate -- not sure why they're here in
this same patch.

There must be some way of generating bitmaps with the appropriate color profile
without changing the system color profile -- we're not even rendering to the
screen!

r=me

[Eric Seidel (no email)]

Maciej and I are in the midst of conversation with the CoreGraphics folks about just that topic... I'll wait to 
commit this until we have a more definative answer from them.

[Alexey Proskuryakov]

Is it the same as bug 5962?

[Eric Seidel (no email)]

*** Bug 5962 has been marked as a duplicate of this bug. ***

[Eric Seidel (no email)]

We need to find a nicer way to do this.  But at least this is a step forward for now.  Landed after replacing 
atexit with the appropriate signal handlers (to better handle failure cases) and addressing darin's 
concerns.