Bug 6155

Summary: DumpRenderTree should set a consistent color profile while running
Product: WebKit Reporter: Eric Seidel (no email) <eric>
Component: Tools / TestsAssignee: Eric Seidel (no email) <eric>
Status: RESOLVED FIXED    
Severity: Normal CC: ap
Priority: P4    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Attachments:
Description Flags
Proposed patch. darin: review+

Eric Seidel (no email)
Reported 2005-12-19 19:56:51 PST
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.
Attachments
Proposed patch. (5.76 KB, patch)
2005-12-19 19:59 PST, Eric Seidel (no email) 		darin: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2005-12-19 19:59:35 PST
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 2 2005-12-19 20:00:15 PST
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 3 2005-12-19 20:20:43 PST
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)
Comment 4 2005-12-19 20:54:06 PST
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
Comment 5 2005-12-21 23:17:30 PST
Is it the same as bug 5962?
Eric Seidel (no email)
Comment 6 2005-12-22 01:39:59 PST
*** Bug 5962 has been marked as a duplicate of this bug. ***
Eric Seidel (no email)
Comment 7 2005-12-29 22:38:10 PST
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.
Note You need to log in before you can comment on or make changes to this bug.