Last Comment Bug 53878 - Mozilla color image handling code is different from the bgcolor color handling code
: Mozilla color image handling code is different from the bgcolor color handlin...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: Trunk
: x86 All
: P3 normal with 1 vote (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://hotwired.lycos.com/webmonkey/0...
Depends on:
Blocks: 61530
  Show dependency treegraph
 
Reported: 2000-09-22 22:50 PDT by xkahn
Modified: 2012-01-13 14:36 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description xkahn 2000-09-22 22:50:08 PDT
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16 i686)
BuildID:    2000091312

The bgcolor attribute rounds to one color in the color cube, and the image code
rounds to another in 16 bit mode.  (At least on Linux.)  Check out this URL to
test:
http://hotwired.lycos.com/webmonkey/00/37/stuff2a/complete_websafe_216/test.html

Razorfish wrote an article on the problem which can be found here:
http://hotwired.lycos.com/webmonkey/00/37/index2a.html?tw=design

This link ( http://www.zoned.net/~xkahn/boxes.png ) shows mozilla rendering this
page on Linux in 16bit True color mode (here is the xdpyinfo)
  default visual id:  0x22
  visual:
    visual id:    0x22
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits


Reproducible: Always
Steps to Reproduce:
1. Load the URL in 16bit mode.
2. Look for boxes within boxes.  Each one you see is a bug in the color
handling.

Actual Results:  Boxes within boxes everywhere!

Expected Results:  A nice clean set of solid boxes.

Gimp says:  CCCCCC bgcolor is: C8CCC8, and CCCCCC image is dithered to: c8c8c8
and c0ccc0.
Comment 1 Syd Logan 2000-09-22 22:53:16 PDT
You have to look carefully, some of the images that have a high luminosity (like
cccc99) are easier to see a problem with than those which are less luminous. I
saw this too on my 16-bit system.
Comment 2 Asa Dotzler [:asa] 2000-11-01 16:36:35 PST
setting bug status to New
Comment 3 Paul Wyskoczka 2000-11-02 07:14:57 PST
Updating QA Contact
Comment 4 Paul Wyskoczka 2000-11-02 07:17:01 PST
Adding myself to cc list
Comment 5 pnunn 2001-03-19 14:23:02 PST
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Comment 6 basic 2001-07-02 11:22:46 PDT
Seeing this on build 2001070108 win32 on win98

setting os to all

are there any plans to fix this?
Comment 7 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-09-06 20:49:50 PDT
Is this a duplicate of bug 1759?
Comment 8 Christian :Biesinger (don't email me, ping me on IRC) 2002-03-28 06:26:56 PST
dbaron, I don't think so, since in this bug no transparency is involved (as I
understand it)
Comment 9 Cees T. 2007-03-19 10:12:08 PDT
Test page looks fine in Firefox 2.0.0.2 on K/Ubuntu 6.10.
Comment 10 Cees T. 2007-03-19 10:23:34 PDT
Sorry, it turns out i'm running with 24 bit colors. KDE doesn't appear to have a color depth setting in its GUI. I'll test and report back if it's OK.
Comment 11 Jeff Muizelaar [:jrmuizel] 2012-01-13 14:36:39 PST
We no longer do dithering.

Note You need to log in before you can comment on or make changes to this bug.