Closed Bug 31726 Opened 25 years ago Closed 1 year ago

Allow tinting of bitmap graphics for chrome

Categories

(Core :: XUL, enhancement, P3)

enhancement

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: mpt, Unassigned)

References

Details

Skins should have the ability to tint graphics which are used in the chrome -- such as toolbar button icons, and graphics used for XBL effects. A chrome author would draw button graphics in a neutral color scheme. Then a skin author would come along and decide that they want to have (for example) a blue color scheme. So the icons are tinted to a particular shade and a particular intensity -- e.g. moz-tint-color: #00f moz-tint-level: 50% That way you could have the subtle shading and transparency of bitmap graphics, *and* flexibility in color. So you could change your color scheme without having to use a completely different set of graphics. This would make skinning Mozilla a lot easier. For example, the colored bits of David Hyatt's Aqua skin could be drawn in gray scale, and a tint applied to them. Then the hue of the colored parts of the section could be changed later, with one line of CSS (or it could even use CSS2's UI colors). I'm putting this in Browser-General for now because it needs work from at least two components (that I can think of): * ImageLib, to implement the tinting * Style System, to recognize the moz-css tinting property.
Updating component and owner.
Assignee: cbegle → trudelle
Component: Browser-General → XP Toolkit/Widgets
QA Contact: asadotzler → jrgm
I've had this in my mind for a while to. The simplest case, only -moz-tint-color: Red is the input tint-color. Green is ignored (should be the same as Blue) let R,G,B be the input rgb values and r,g,b the output rgb values in the range 0-255 if (B==255) tint=0; else tint=(R-B)/(255-B); r=B+tint*(tintColorR-B) g=B+tint*(tintColorG-B) b=B+tint*(tintColorB-B) It is possible to have two tint-colors: Draw a greyscale picture. Tint it with red and green. Then the blue channel still has the greyscale information. If you look at the aqua skin, you'll see that the blue fades to cyan at the bottom of the widgets. So there's a clear need for two tintcolors. The most complex case: -moz-tint-color: #fc0 #0cf; -moz-tint-level: 80% 70%; (Do we really need a -moz-tint-level? Could someone give a real-life example?) The math: if (B==255) {tint1=0;tint2=0} else { tint1=tint1Level*(R-B)/(255-B) tint2=tint2Level*(G-B)/(255-B) } r=B*(1-tint1)*(1-tint2)+tint1ColorR*tint1+tint2ColorR*tint2 g=B*(1-tint1)*(1-tint2)+tint1ColorG*tint1+tint2ColorG*tint2 b=B*(1-tint1)*(1-tint2)+tint1ColorB*tint1+tint2ColorB*tint2 Note that these values need to be corrected for overflow, which happens when the greyscale value is low and both tint-levels are high. Note 2 that it might be quite difficult to convert the aqua screenshots to a twofold tinted image, and get the original result back after the math above. Another possible solution is to require R>=G>=B, where Red sets the tint level and Green slide between one tint-color (G==B) and the second (G==R). A source image would only have grey, red and yellow colors. It is less flexible (only one tint-level) but closer to what's really needed. Then the math would be: if (B==255) tint=0; else tint=tintLevel*(R-B)/(255-B); if (R==B) color=0; else color=(G-B)/(R-B); r=B+tint*(tint1ColorR+color*(tint2ColorR-tint1ColorR)-B) g=B+tint*(tint1ColorG+color*(tint2ColorG-tint1ColorG)-B) b=B+tint*(tint1ColorB+color*(tint2ColorB-tint1ColorB)-B)
reassigning to hyatt for consideration, and probable latering.
Assignee: trudelle → hyatt
yes, I had been meaning to file a similar bug. This is probably one of the biggest problems with skins right now.
Status: NEW → ASSIGNED
Target Milestone: M17
should -moz-tint-* apply to both background-image and list-style-image? Or is another property needed like: -moz-tint-image: background list-style; which is easily extended for other images in the future.
My formulas are not really good. With tintcolor #f00 and tintlevel 100%, the calculations should return the original image, which they don't. I'll have to think of other methods.
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
You probably already read about this in n.p.m.ui, but here goes anyway: Tinting bitmaps is currently possible with the PNG alpha channel. The drawback is that the alpha channel can't be used for other purposes at the same time. A demo is at: http://www.pp.htv.fi/hsivone1/css-test/bitmapstyle.html
Is it possible to lay another PNG on top of the first? Then it would be a second alpha channel.
I suppose it is possible to place two images at the same location. It does not solve the problem, however. To use alpha channels for both tinting and regular transparency, you'd need JavaScript methods for generating virtual PNGs on the fly. ie. composite a PNG on a colored box take the resulting RGB channels and generate a new virtual image file out of them add an alpha channel from another real file to the virtual file composite the virtual image file onto some arbitrary background
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Blocks: 46174
Target Milestone: M21 → Future
No time left to add non-critical features to NS6, ->future
*** Bug 45501 has been marked as a duplicate of this bug. ***
*** Bug 140226 has been marked as a duplicate of this bug. ***
Would this make it possible for an image to be shown in system colors? One concern I have with my Internet Explorer skin is the disabled image. IE uses the ThreeDShadow color (with ThreeDHighlight offset) for the disabled back button while IE skin uses a dark-gray image with a white offset. I would want the ability to map the dark-gray entry of the palette to ThreeDShadow and the white to ThreeDHighlight. This would make my skin more faithful to the original and, more importantly, to avoid the usability problems present in my skin which are not present in IE. Off topic: MPT mentioned David Hyatt's Aqua skin. Where can I find this?
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
Target Milestone: Future → ---
back to the future...
Target Milestone: --- → Future
Blocks: 112580
Assignee: jag → nobody
QA Contact: jrgmorrison → xptoolkit.widgets
Severity: normal → S3

XUL + no activity for a while. Closing.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.