Closed
Bug 459617
Opened 16 years ago
Closed 15 years ago
color management reftest failing in Ubuntu
Categories
(Core :: Graphics: Color Management, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: zadkiel.m, Unassigned)
References
Details
Attachments
(1 file)
169.28 KB,
application/zip
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b1pre) Gecko/20080929132416 Minefield/3.1b1pre Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b1pre) Gecko/20080929132416 Minefield/3.1b1pre Firefox rendered from images color profiles are not passing reftests in Ubuntu. Firefox renders comes from purposely failing a reftest to get at the URI data Firefox uses to do tests with. Reproducible: Always Steps to Reproduce: do steps 1-5 on mac/win (to isolate the Ubuntu) step 6 is done on the Ubuntu and compares the firefox rendered reftests(on the mac/win) and the image with the profile. 1. get an image 2. apply a .icc colour profile to it. 3. write and run a reftest that fails on purpose -the output of the failed test includes a URI of the image that firefox renders(which is a forced sRGB during tests) 4. take the uri data and paste it in the address bar of firefox 5. save and crop the uri image 6. write and run another reftest that compares the image with the profile from step 2 and the saved and cropped image in step 5 Actual Results: Isolated 2 pixels with profiles and redid the test and they both failed Pixel with profile Adobe 1998 with Adobe Profile 8ca39b = firefox render 82a49c fails on the Ubuntu with Adobe Profile 6f8753 = firefox render 63884f fails on the Ubuntu Expected Results: The reftest should pass when done on any platform.
Comment 2•16 years ago
|
||
What is the ubuntu rendering for the two problem pixels? ie - is it an off-by-one issue, or something else?
I managed to replicate it on Fedora 8 and Ubuntu. It's off-by-one on the red channel I think.
Component: General → GFX: Color Management
Product: Firefox → Core
QA Contact: general → color-management
Version: unspecified → Trunk
Comment 4•15 years ago
|
||
Update since most of this has been being discussed over email: Zad managed to determine that the problem is that the linux machines he's using are using the fixed point path rather than the optimized sse2 floating point path, and these two paths occasionally differ (the second part is a known and unfixable issue). Upon further inspection, it seems like a preprocessor issue. The two macros tested are __GNUC__ and __i386__, and it seems that on Zad's linux machines __i386__ is not defined. Zad, what version of GCC are you using? Vlad, any idea if there's a more appropriate #ifdef to use?
Mac gcc version 4.0.1 (Apple Inc. build 5490) Linux gcc version 4.3.1 (Ubuntu 4.3.2-1ubuntu11)
You're on x86-64, if the user agent in the initial comment is correct. i386 != x86-64, so __i386__ won't be defined. If the code really is compatible with x86_64 (that is, it's SSE2 etc and not MMX), then you can also check for __x86_64__ and __amd64__.
Comment 7•15 years ago
|
||
Zad - want to give vlad's suggestion a try?
Comment 8•15 years ago
|
||
You can also do a sanity check by building a 32-bit Firefox on your 64-bit system: https://developer.mozilla.org/en/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS
Reporter | ||
Comment 10•15 years ago
|
||
changed line http://mxr.mozilla.org/mozilla-central/source/modules/lcms/src/cmsxform.c#96 http://mozilla.pastebin.com/f5093919d it hangs up. lookin' into the 32-bit on the 64-bit on the ubuntu not givn'r
Comment 11•15 years ago
|
||
you definitely want GNUC no matter what, and then within that you want an OR of all the possible architectures. so you want #if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__) || defined(__amd64__))
Reporter | ||
Comment 12•15 years ago
|
||
it is crashing gdb: bt ouput http://pastebin.com/f36433f37
Is there maybe another place where you also have to allow x86-64? Could grep for __i386__ and see what's conditional on that.
Comment 14•15 years ago
|
||
can you post your "hg diff" to make sure that nothing else is being modified?
Reporter | ||
Comment 15•15 years ago
|
||
sure thing http://pastebin.mozilla.org/608716
Comment 16•15 years ago
|
||
Oh right, there's a bug for this. Marking it as blocking us. I'll ping that bug and see what the status is.
Depends on: 456028
Reporter | ||
Comment 17•15 years ago
|
||
tested it on the i686 linux and it passes.
Reporter | ||
Comment 18•15 years ago
|
||
tested the patch on an x86-64 https://bugzilla.mozilla.org/attachment.cgi?id=356334 and it passes
Reporter | ||
Comment 19•15 years ago
|
||
tested again with the nightly and it passed https://bugzilla.mozilla.org/show_bug.cgi?id=463221#c10
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•