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.
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.
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.
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
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.
Is it the same as bug 5962?
*** Bug 5962 has been marked as a duplicate of this bug. ***
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.