Last Comment Bug 423756 - Request: Switch for authors to turn on/off bilinear filtering when enlarging images
: Request: Switch for authors to turn on/off bilinear filtering when enlarging ...
: dev-doc-complete
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
: -- enhancement with 85 votes (vote)
: ---
Assigned To: Robert Longson
: Milan Sreckovic [:milan]
: 438775 456183 472981 (view as bug list)
Depends on: 484150 487160
Blocks: 486933 486934 486935 486936
  Show dependency treegraph
Reported: 2008-03-18 16:09 PDT by Scott Hackman
Modified: 2010-09-27 16:22 PDT (History)
56 users (show)
longsonr: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

add hidden pref for this (gfx.images.smooth_scale) (6.43 KB, patch)
2009-01-09 14:43 PST, Vladimir Vukicevic [:vlad] [:vladv]
joe: review+
Details | Diff | Splinter Review
patch (32.84 KB, patch)
2009-04-01 14:40 PDT, Robert Longson
vladimir: review+
joe: review+
Details | Diff | Splinter Review
address review comments (35.07 KB, patch)
2009-04-02 02:30 PDT, Robert Longson
roc: superreview+
Details | Diff | Splinter Review
reftest (2.52 KB, patch)
2009-04-02 10:35 PDT, Robert Longson
roc: review+
Details | Diff | Splinter Review

Description Scott Hackman 2008-03-18 16:09:19 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

I think that bilinear filtering on enlarged images should be optional, controlled by a switch in about:config if nowhere else. While it works well on some things, it doesn't work well on things like, say, videogame sprites used for forum avatars that are then enlarged. They just look blurry. shows that there seems to be something wrong with the bilinear filtering that adds stray pixels in an animated image (lines appear to extend from the character's hair and boot in that image, and I've seen it happen elsewhere on that site -- Haven't checked it with other sites, though).

Reproducible: Always

Steps to Reproduce:
Look at any place where an image, particularly a pixel art image, is resized.
The Kid Radd webcomic, as an example, is full of these.
Actual Results:  
The image becomes blurry.

Expected Results:  
An option allows me to change things so that the image remains sharp when enlarged.
Comment 1 Kai Liu 2008-06-09 13:24:53 PDT
Also see <>

I think it makes some sense to disable the smoothing if the scaling factor is an integer...
Comment 2 Kai Liu 2008-06-12 04:49:30 PDT
*** Bug 438775 has been marked as a duplicate of this bug. ***
Comment 3 Zak 2008-07-03 01:12:34 PDT
I think the best way to solve this would be to smooth JPEG images only. Since nobody uses JPEG images for pixel art, it wouldn't cause any problems. Leave GIF, PNG & BMP as nearest neighbor filtering.
Comment 4 BoffinbraiN 2008-08-16 22:36:43 PDT
See also:

I also agree with the notion that filtering should only be applied to inherently lossy image formats like JPEG whose purpose is not for sharpness or fine detail.  The inability to turn this off is a nightmare for designers.
Comment 5 Jeff Stewart 2008-08-19 15:39:02 PDT
There's also a performance consideration.  Bilinear filtering can dramatically reduce animation framerates if the animation involves scaled bitmaps, and the performance penalty increases with the scaling factor.  We're having this problem at work right now; we use browser scaling to pixellate sensitive imagery because it's so much more efficient than storing equivalent scaled renditions.  But when those images are dragged, FF takes a performance hit that we don't see in other browsers.

An agent-specific CSS property (ala -moz-disableFiltering) would afford authors the correct amount of control over filtering while eliminating "best-guess" heuristics that constrain design decisions.  Remember, JPEG can be made lossless.  And lossless photographs (PNG and BMP) look better under bilinear filtering than nearest-neighbor, while lossless line art (diagrams, etc.) tends to look better under nearest-neighbor.
Comment 6 Lech Deregowski [:lech] 2008-09-20 06:23:34 PDT
Might as well mark bug 456183 as a duplicate which I filed earlier before finding this one. 

But I think this should be disabled by default or at least for images under a certain size regardless of format. While I like Jeffs' agent-specific CSS property, it would be better if the option was only to enable it for those who want it as it adds some unwanted and unnecessary markup. This prevents users from being surprised by something only Firefox is doing to their images while other browsers aren't.
Comment 7 Lech Deregowski [:lech] 2008-09-21 11:53:03 PDT
*** Bug 456183 has been marked as a duplicate of this bug. ***
Comment 8 Vladimir Vukicevic [:vlad] [:vladv] 2008-09-21 22:27:17 PDT
(In reply to comment #6)
> This prevents users from being surprised by something only Firefox
> is doing to their images while other browsers aren't.

Firefox 3, Safari, and IE8 (IE7 as well, I think) all apply bilinear filtering to all imeages when upscaling.  Opera might as well, haven't checked.
Comment 9 Alex McLeod 2008-10-02 02:35:42 PDT
Anyone using image up-scaling *on purpose* is going to find that bilinear filtering completely ruins the look they're going for.

pixel art, including animated gifs and forum avatars
graphics programming diagrams & examples
technical photography articles & forums

Basically, any website that concerns itself with *pixels* may be rendered incorrectly because of this bilinear filtering. Not just incorrectly, either, but also unpleasantly; for any end user with text antialiasing disabled, a website showing a mix of sharp text & blurry images (including logos etc.) will look pretty bad when zoomed.

The Image Zoom addon now renders images unpleasantly blurry, too (since Firefox 3.0.3), making an excellent addon almost entirely useless. It can no longer be used for getting a closer look at an image, because with filtering it shows *less detail*, completely defeating the user's intention.

An option to disable filtering at scales >100% (regardless of image format) is, in my opinion, absolutely necessary.

To put it another way: if you woke up one day and found your monitor was applying a "smoothing" filter to everything it displayed, and you couldn't switch it off, how many stories would it fall when you threw it out the window?
Comment 10 Minales Robins 2008-10-07 17:39:53 PDT
@comment #9
That doesn't apply to us that use sited that use Pixel graphics that are upscaled automaticly.

like the GaiaOnline Customize Avatar feature.
for Example.
Here is the Image
GaiaOnline Automaticly Stretches that that on the site which with this darn blur filter think, it makes it look like this
See how blury it is because of the filter.

We can't just change that ourselves becasue that's embeded into the site.

That has nothing to do with the zoom feature, tha'ts just resized image which gets blured.
It's a PNG graphic which having the bilinear filter on a PNG is completly useless as it is...
Comment 11 asmpgmr 2008-10-30 10:22:08 PDT
Another site which displays resized pixel art (GIFs) which is now blurred -
Comment 12 BoffinbraiN 2008-10-30 10:39:38 PDT
Resized images for the purposes of allowing the user to 'zoom in' and see extra detail are used all over the Internet.

Since making an image larger than its original dimensions yields no further detail, bilinear filtering is only useful when the image is *reduced* in size, to reveal lines of pixels that would otherwise be dropped completely.

I suggest applying the filtering only when the image is displayed with smaller dimensions than its actual size.  This allows people to continue to zoom images as normal, while making other images smooth as intended.

Or, of course, make it an option in about:config at least.
Comment 13 Maxim 2008-10-30 10:55:47 PDT
(In reply to comment #11)
> Another site which displays resized pixel art (GIFs) which is now blurred - 
Actually if you have Javascript turned on we go to some effort to redraw the image with squares in a <canvas>, so it's not a great example.

An about:config setting is a bad idea, custom CSS ideal.
Comment 14 asmpgmr 2008-10-30 11:27:13 PDT
Confirmed, I added to my Javascript whitelist and the images display properly now. But I still say that something should be done about this as it breaks other sites which use upscaled pixel art.
Comment 15 BoffinbraiN 2008-10-30 16:55:37 PDT
(In reply to comment #13)

Why would an about:config setting be a bad idea?  Anyway, I agree that it should be a last resort only.

Adding another non-standard CSS attribute to Firefox's repertoire doesn't sound like a great idea to me.
Comment 16 Maxim 2008-10-31 02:41:06 PDT
It makes more sense for particular sites to be able to control the rendering of individual images, than for a single (hard-to-access) browser setting to globally control the rendering of all images on all sites.

For almost all downscaling, and non-integer upscaling of photographic images (which may be paletted), filtering is good. For integer upscaling of pixel art (which may be 24bpp), filtering is bad. Switching behaviour on the transition from 1.99 to 2.00 is bad. So algorithmic approaches are a bad idea.

Of course a new CSS attribute is ugly, especially since it hasn't really got any application to elements other than images, but how else can page designers control this?
Comment 17 Vladimir Vukicevic [:vlad] [:vladv] 2008-10-31 12:46:49 PDT
SVG has the image-rendering property -- -- which could be uplifted to HTML for this purpose.  I think that SVG's is somewhat misguided though; optimizeQuality vs optimizeSpeed does not make a clear distinction between filtered or non-filtered.  I'd suggest a new image-filtering property which just sets whether images should be filtered or not when scaled.
Comment 18 John-Paul Williams 2008-12-04 03:54:00 PST
Is nothing being done with this? I know most users probably don't even notice the bilinear "feature" in firefox, but when you need to see an unfiltered image (which I for one often have to) I am forced to use another browser... I'm now using Opera to do this, which is annoying. By its nature upscaling is a destructive process.

It should be the decision of the content creator to optimise images (choosing their own non-lossy format)properly. This "feature" being on by default means that sites are being rendered with unwanted filtering which is against the ethos of a "standards compliant" browser and should be an optional element.

This "feature" of firefox should be disabled or optional in the next release. Until then, I will be using Opera.
Comment 19 Jan Krejci 2008-12-16 23:12:43 PST
This stupid feature just kills FF3 for me. Im still using FF2 but now its at the end of life and im forced to migrate to Opera. Im sad but thats the life...
Comment 20 sanjuro 2008-12-25 09:03:37 PST
Same here. I'm still using Firefox 2 and switch sometimes between this and Opera, which has a great handling of image scaling. You should really kill off this function. I run a website about retrogaming and under FF3 it looks disfigured, obviously many other sites with the same theme are affected too. On the other hand, I can't think of a single instance where this feature has been useful.
Comment 21 - 2008-12-29 23:46:42 PST
This forced antialias is a big no-go!

As someone else already mentioned, resized "pixelart" images now look really ugly. More websites where this "feature" is terribly annoying are HOL and Lemonamiga, two examples: (click on a thumbnail, then on "2x" above the screenshot to resize it) (click on a thumbnail in the list, then click the big screenshot to resize it)

I think this "feature" should be dropped, no matter what image format. If at all, make it an opt-in function in the options window, NOT somewhere hidden in about:config (which most Firefox users don't know because they aren't nerds and don't care).

What where the FF3 coders thinking about implementing a "feature" (and a few more) that nobody wants?
Comment 22 kyle pulver 2008-12-30 01:18:29 PST
So this hasn't been addressed yet?  I still have to use IE6 to view pixel art properly.
Comment 23 Maxim 2008-12-30 01:59:51 PST
In the interests of balance, here's some arguments the other way:

Since other browsers are moving towards filtered scaling, it may be a fait accompli, but not making it configurable is a real pain.

I may as well pimp our solution: which redraws the image as squares on a canvas, but it's not universal (canvas support being rather messy between browsers) and designed for 1-bit alpha.
Comment 24 Ryan VanderMeulen [:RyanVM] 2008-12-30 06:42:40 PST
Guys, it's great that you're enthusiastic about seeing this get resolved, but spamming the bug is not the proper way to do that. All it does is send a LOT of mail to a LOT of people (many of whom aren't developers) and bury any comments useful for fixing this bug under all the other ones, making it harder for someone to pick up and work on. Please read the etiquette guidelines before posting more comments. If you want to discuss this further, please take it to the newsgroup.
Comment 25 Alex Faaborg [:faaborg] (Firefox UX) 2008-12-31 18:28:28 PST
>controlled by a switch in about:config if nowhere else

If we add a pref, I think it should only be in about:config.  The vast majority of users won't be able to make an informed decision.
Comment 26 David B. 2009-01-08 00:20:05 PST
As a web designer myself, there are a few web-tricks I do with *.gif images that consist of resizing a 2px image and stretching it for various purposes. In some testing I've noticed that this aliasing shows up. I really believe that aliasing should only be applied for lossy formats (jpeg, etc) or vector formats. I'm a tad frustrated that it isn't even an option... but now the majority of browsers have made the decision to alias formats that shouldn't be aliased. Where was this discussion?
Comment 27 Vladimir Vukicevic [:vlad] [:vladv] 2009-01-09 14:43:13 PST
Created attachment 356253 [details] [diff] [review]
add hidden pref for this (gfx.images.smooth_scale)

Ok, here's a patch that adds a hidden pref ("gfx.images.smooth_scale") that can be set to disable smooth scaling of images.  Patch is a bit bigger than you'd think since I reused the existing pref observer and just renamed it some in gfxPlatform.

We really need a CSS attribute to control this; SVG unfortunately has nothing that we can reuse here, because its CSS attributes are focused around making a performance or quality tradeoff, not about explicitly specifying filtering.
Comment 28 Daniel 2009-01-11 03:39:06 PST
If I understand it right: Joe needs to review this, and if he approves the patch it will be included in the next ff update?

Is there a possibility to use this function before the next update, without messing with the source code?
Comment 29 Joe Drew (not getting mail) 2009-01-13 13:11:00 PST
Comment on attachment 356253 [details] [diff] [review]
add hidden pref for this (gfx.images.smooth_scale)

>-                pattern->SetFilter(0);
>+                pattern->SetFilter(gfxPattern::FILTER_NEAREST);

I presume FILTER_NEAREST is the same as FILTER_FAST, and thus the same as 0?

>+    if (!gfxPlatform::ShouldSmoothScaleImages()) {
>+        pattern->SetExtend(doTile ? gfxPattern::EXTEND_REPEAT : gfxPattern::EXTEND_NONE);
>+        pattern->SetFilter(gfxPattern::FILTER_NEAREST);
>     }

Why is the SetExtend call necessary? 

>-    void SetFilter(int filter);
>-    int Filter() const;
>+    enum GraphicsFilter {
>+        FILTER_FAST,
>+        FILTER_GOOD,
>+        FILTER_BEST,
>+    };

There should probably be a comment here saying that "either this enum must be the same as cairo_filter_t, or SetFilter must be changed."

r+ otherwise.
Comment 30 Daniel 2009-02-06 00:47:36 PST
So... When will this thing work?
Comment 31 PP 2009-02-10 23:59:14 PST
We really need this CSS enhancement ... it completly ruins our business
Comment 32 Flo Ledermann 2009-02-11 02:38:24 PST
I completely second PP's and all the other comments. How could this *ever* go into the release without being thought over?

The *site author* has to be able to control image scaling behaviour, there's a -moz- css attribute for so many other things, so why not for this?

I am following the mozilla project since M5 or so, this is the one issue that has deeply shaken my confidence in the project and the people responsible for making decisions here. Not a good thing in the current rising of Chrome and other browsers to scare away the old-school supporters like this.
Comment 33 Patrick Vernon 2009-02-11 05:31:55 PST
Well, except that Chrome does it too. (

Unfortunately, I think this is going to be the norm in a year or so.
Comment 34 Alex McLeod 2009-02-11 06:33:18 PST
I agree that the site author should to be able to control image scaling behaviour - but also as a USER, I never, ever want to see an image up-scaled with anything but nearest-neighbour filtering, because every alternative is BLURRY and HORRIBLE.

Down-scaling methods are (generally) okay. The problem is that Firefox now BLURS any images that it up-scales, because that's the nature of bilinear filtering, like biting and mauling are the nature of tigers. There is just NO FILTERING METHOD that can up-scale an image in a way that looks as good as the original. NONE AT ALL.

Please, let this be fixed; the web has been unpleasantly blurry for long enough.

Nearest-neighbour filtering for integer up-scale factors (like x2, x3 or x4) would be ideal. Binning for 1/integer down-scale factors (like /2, /3 or /4) would also be ideal. Seriously - how is this not obvious? What is wrong with this idea? How has this bug gone unaddressed for almost a year when the ideal solutions are so obvious?
Comment 35 Daniel 2009-02-13 01:15:14 PST
Yup, and than just everyone who would not like his image pixelly have to resize it 199%, or 299% or 301 or whatever.
It would work, but id prefer a css atribute, AND an option to set it automatic to what you want yourself. As Vladimir coded.

When will that be included in firefox? Vladimirs fix? :?
Comment 36 Stevens 2009-03-05 14:19:11 PST
Is there some 'particular' reason why people are dragging their feet on this fix?  This is something that really should have been a choice from day one, and it's taken a year since it was reported for someone to even look at implementing an on/off setting?  This seriously brings into question the competency of some Firefox developers.
Comment 37 Johan Hanberg 2009-03-05 15:50:30 PST
How tricky would it be to write an extension to do this? As a non-programmer I really have no idea.

I really hope this gets fixed soon. Having to switch to Opera every time I want to look at zoomed images on sites like Pixeljoint or Lemonamiga or such is getting extremely annoying.
Comment 38 TakaM 2009-03-05 16:13:24 PST
I recently reinstalled windows (and firefox) so when it auto-updated to FF3, I actually used IE for a brief period.
How dare you mozilla.
Comment 39 Johan Hanberg 2009-03-13 12:29:18 PDT
So a fix has been available for just adding now for a few updates right? Does anyone know why this is never happening?
Comment 40 crabby 2009-03-17 14:36:49 PDT
Very disappointing that firefox still hasn't included a simple option allowing enabling or disabling of the Great Blur. I just don't understand why there's so much choice in just about every area of firefox, but none here.
Comment 41 Daniel 2009-03-18 01:55:01 PDT
I have just mailed Joe, I hope he can provide some more info. If not, I will send an email to vladimir too.
Comment 42 mail 2009-03-18 04:28:13 PDT
Can this issue be fixed for Firefox 3.1/3.5 (like in IE)?

It is very disappointing that this critical issue has been open for a full year now. Just do a google search, in every discussion about the smooth rescaling feature people complain about this bug.
Comment 43 2009-03-18 09:21:49 PDT
Dolefully, in linux version of Firefox bilinear filtering is not even implemented.

It seems to me that in compare with users of propietary software linux users are not a priority to Mozilla.

Comment 44 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-03-25 16:52:51 PDT
(In reply to comment #43)
> Dolefully, in linux version of Firefox bilinear filtering is not even
> implemented.
> It seems to me that in compare with users of propietary software linux users
> are not a priority to Mozilla.

Incorrect. It's because we need to use bilinear sampling with EXTEND_PAD in Xrender and most Linux drivers support that extremely poorly due to bugs. See this cairo thread for details:

But there is good news for this bug. Bug 484150 adds support for the SVG "image-rendering" CSS property, with an extension value "-moz-disable-resampling" which does what you want --- but only for SVG images, in that patch. We can and should do a followup patch to let that property apply to HTML <img>s and maybe even CSS background-images. We can easily do that here in this bug after 484150 has landed.

Robert Longson (who is implementing image-rendering for SVG) even proposed that the disable-resampling property value be standardized:
It looks like it may be adopted, with the value named "crispEdges".
Comment 45 Stevens 2009-03-28 01:30:39 PDT
I don't mean to be rude, Robert, but rather than address someone asking 'for' bilinear support in the Linux build, why can't you give us an update on the status of making bilinear filtering optional for Windows users?
Comment 46 Jonathan Watt [:jwatt] 2009-03-28 03:26:49 PDT
Stevens, the first paragraph was about supporting bilinear filtering on Linux, sure, but that was only the first of three paragraphs. The second and third paragraphs seem to be an update on the status of making bilinear filtering optional, no?
Comment 47 Kroah 2009-03-28 09:55:52 PDT

Because the resampling effect is a regression from previous version of Mozilla, this property "disable-resampling" should be enabled by default. This way, no update has to be done to our website.

This is fundamental that this resampling is disabled by default, like that was the case for previous version of Mozilla.
Comment 48 Vladimir Vukicevic [:vlad] [:vladv] 2009-03-28 10:46:34 PDT
(In reply to comment #47)
> Robert,
> Because the resampling effect is a regression from previous version of Mozilla,
> this property "disable-resampling" should be enabled by default. This way, no
> update has to be done to our website.

That part won't happen; resampling images is a net increase in quality for the majority of users.  When specific use cases make it less desirable, the CSS property will be there to provide that control.  If you wish to disable it on all images on your site, I suggest putting a CSS rule for all img elements somewhere on your site; if you wish to disable it for all sites yourself, you can add it to userContent.css.
Comment 49 John-Paul Williams 2009-03-28 17:08:19 PDT
Vladimir, how does the average user know how to operate your 'fix'?

I find it difficult to believe this 'feature' increases overall quality for the majority of users. The very concept of resampling or filtering image content means a distortion. With low resolution content this is incredibly destructive.

Your reply suggests that there be yet ANOTHER workaround by designers to compensate for ignorant developers. The job of a browser is to display content as it was created. Why should anybody to have to put in workarounds for zooming content?

What happened to web standards here? Why is it so hard to just implement a button in preferences that switches this 'feature' on/off. My vote is that this should be part of your initial setup process. I vehemently agree that this should be disabled by default and I find it laughable that you think screwing with content is an advantage in a browser. Isn't that a very IE way of thinking?

The user at some point should be asked if they want images to be filtered. I certainly do not buy the reasoning that it's 'better' for a majority of users. On what basis? Did you put this 'feature' out for any public consultation? I certainly haven't seen any - it seems it was simply added to FF3.

Another suggestion is to place a 'unfilter/filter' option on right click (of image).

If a person in windows wants to see an image as a horribly blurry mess - they simply need to view it in explorer - its simple enough to do and should not be dictated by your browser (imho). Is this really that hard to fix?
Comment 50 Stuart Parmenter 2009-03-28 17:51:44 PDT
Are you actually serious or was your last post a joke?
Comment 51 Daniel 2009-03-29 02:00:48 PDT
Also I believe for the majority of users it is better to have the images filtered etc.
The right click filter is a great idea in my opinion btw.

Here is what would look perfect to me:

Most images automatically filtered, this is changeable in the config
Indexed PNG and GIF images not automatically filtered, this is changeable in the config
Right click filter/nonfilter enables the user to change things in one specific case
Webmasters should be able to set an attribute that changes their cases too, for example even though auto filter is on, he can still make his 24bit PNG's to be not filtered.

Would there be any use of a filter on Indexed PNG's and Gifs?
Comment 52 Dan Weiss 2009-03-29 07:50:29 PDT
If you make it only disable bilinear filtering for any indexed color image, as long as it's an integer scaling factor, and make it the default setting, that should be perfect.
Comment 53 Daniel 2009-03-29 08:22:04 PDT
Well, I know quite a few non indexed PNG images that would not need the filter, and quite a few non indexed PNG images that do. Those PNGs might become a problem. Furthermore I agree with you.
Comment 54 Kroah 2009-03-29 09:19:47 PDT
(In reply to comment #53)
> Well, I know quite a few non indexed PNG images that would not need the filter,
> and quite a few non indexed PNG images that do. Those PNGs might become a
> problem. Furthermore I agree with you.

You're right, we have lots of 24bits PNG images which should not be filtered.

But those images have ALL an integer scaling factor. I don't see any uses to filter images with integer scaling factors, really. If so, the default behavior for these should be "no filter" imho for retro compatibility.
Comment 55 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-03-29 14:52:07 PDT
Switching the default to nearest-neighbour only is not going to happen. If you want to keep talking about it, please file another bug for that.

This bug is about providing author control. If you keep talking about other topics (like a change to the default) on this bug, then you are only decreasing the probability that this bug will be fixed by making it harder for developers to deal with this bug.
Comment 56 Robert Longson 2009-03-29 15:10:52 PDT
Vlad, I'm willing to take a crack at using the SVG CSS property for html images if that's OK with you.
Comment 57 Vladimir Vukicevic [:vlad] [:vladv] 2009-03-29 16:12:23 PDT
(In reply to comment #56)
> Vlad, I'm willing to take a crack at using the SVG CSS property for html images
> if that's OK with you.

Absolutely; go for it.. I have a patch here somewhere that added the filter types to gfxPattern, instead of passing magic constants around.  I can't find it right now though; I'll put it up if I find it, since that's probably good cleanup as part of this.
Comment 58 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-03-29 16:53:11 PDT
Robert already added them to gfxPattern in bug 484150 ... I reviewed it, hope that's OK!
Comment 59 Alex Faaborg [:faaborg] (Firefox UX) 2009-03-30 11:47:52 PDT
>This bug is about providing author control.

Adjusting summary to make it clear that this is about author control as opposed to end user control (although as vlad mentions end users who are extremely informed can control this setting with userContent.css).
Comment 60 crabby 2009-03-30 17:58:34 PDT
I thought this bug report was focused on end user control. It stated this in the original post. All this stuff about creating case-by-case scenarios is going against the original intent to simply have a global control availiable through about:config. Having a filter running by default is more than acceptable as Robert(or whoever it was) made the point nicely that the filter is a very pleasing addition for the majority. I'm fine with that and I'm certain many others are, but I NEED to have the option to determine MY own level of filtering(which is none or nearest neighbour). If the switch was for authors, then thousands of site authors would have to overhaul tens of thousands(best case scenario) of pages of video game and other pixel art and that just isn't going to happen. 

I can't agree with the new direction of this bug report.
Comment 61 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-03-30 18:01:13 PDT
You'll be able to add rules to userContent.css to turn off filtering everywhere. If you think a more accessible interface than that is needed, please file a new bug for it.
Comment 62 Gerd Hafenbrack 2009-03-31 02:34:03 PDT
Sir, yes sir!
Are we in the forces here?

Why didn't you file a new bug instead of changing from "Switch to turn on/off bilinear filtering when enlarging images" to "Switch for authors"?

I support Comment #60! This bug is about end user control as simple as possible for the end user. The bug reporter requestet it in about:config. I gave my vote for control in about:config and NOT for an author switch. These votes are captured by you. YOU should file a new bug, if you want a switch for authors!
Comment 63 Daniel 2009-03-31 02:35:58 PDT
Agreed. I want to be able to control things myself instead of having to wait for all my favorite websites to change their settings.
Comment 64 Gerd Hafenbrack 2009-03-31 02:44:37 PDT
With the word "you" I mean Mozilla and not Robert or Alex personally.
Switch for authors is a different bug.
Comment 65 sanjuro 2009-03-31 03:07:19 PDT
Authors should be the priority. Once we make the changes in our websites it will reach a lot more people than the few end users who know how to modify on their own variables in the config; with a Mozilla CSS Extension updating those "tens of thousands of pages" (comment #60) will be a breeze.
Comment 66 TakaM 2009-03-31 04:43:52 PDT
Authors should be the priority? Really?
That sounds like the absolute worst solution to a stupid problem that shouldn't exist in the first place.
At the very least I am never updating to FF3 and I'm probably going back to IE, this whole situation has been nothing but insulting.
Comment 67 Michal Čaplygin [:myf] 2009-03-31 06:01:19 PDT
(In reply to comment #66)
> Authors should be the priority? Really?

This bugs (requests) title is (now) "Switch for authors…". 

The about:config pref (yes, mentioned in the description - what a contradiction) is NOT the solution for authors. But … you can also be "author: (just to sum up what is proposed): You might be able to update the userContent.css (or use the Stylish addon) with something like

img { -moz-scaling-method: fast } /* nearest | bilinear | gaussian | … */

This is IMHO a bit more comfortable than using about:config (my personal opinion) 
and this also would be useful for web developers ("authors") out there. It would be possible to set this up only for exact domains and selectors in userContent.css, what is IMO not simply possible doing in about:config.

As said, if you insist on the global about:config pref, post another request. My opinion is that it would not spoil anything. But if we had just the switch described above, I would be fully satisfied.

(Apologies for my bad English.)
Comment 68 Scott Hackman 2009-03-31 06:32:56 PDT
The problem with making it an author switch only is that some authors may be unaware of the switch and not using/designing for firefox, or someone may be visiting a legacy or abandoned site -- in such cases, the user needs an option to enable this themselves.
Comment 69 Stevens 2009-03-31 07:08:32 PDT
I agree 100% with Scott and Gerd.  My vote went for a user-controlled setting, and you have now rather underhandedly changed it to something else.  Why not just void this entire voting process and do whatever the hell you like if the votes count only for content the developers themselves want to address?  Whoever decided to literally change the purpose of this bug report completely invalidated the point of it and the REASON people have been voting for a fix.

Nice work, you've officially ended my interest in Firefox!
Comment 70 Lech Deregowski [:lech] 2009-03-31 07:22:13 PDT
In the context of authors, a CSS based solution is useful but could a NAME meta tag in the head of the document serve as another option? Something like:

<META NAME="mozscaling" CONTENT="fast" /> 

This way those concerned about CSS validity won't get hit with warnings or errors and it really doesn't affect the document validity.
Comment 71 Santiago Zapata 2009-03-31 07:33:19 PDT
I think we need both a CSS attribute (for authors) and a configuration setting (about:config or anything) (for users).

I also think it's pretty awesome to have a tool such as this to let our voices be heard by the devteam, and being an open source developer I trust whatever way they want to handle requests for enhancement. 

I think this request in special is pretty relevant to a large number of people and I wonder why its importance has not been perceived for such a long time; I hope they will fix it soon though.
Comment 72 Joe Drew (not getting mail) 2009-03-31 08:59:58 PDT
Comment 73 Vladimir Vukicevic [:vlad] [:vladv] 2009-03-31 10:11:37 PDT
Are you people not reading?

As both roc and I said, once the CSS attribute support is added, you'll be able to add the attribute to apply globally to all sites/images by putting the rule in your profile's userContent.css.  There is very little chance that this will be exposed in the UI as a preference, and given the presence of the CSS attribute, not much reason to expose it in about:config.
Comment 74 crabby 2009-03-31 14:41:07 PDT
Rob,Vlad, and the others, thank you for the explanation. Sorry, but this CSS stuff is quite beyond my understanding, so I assumed when the title was changed that optional filtering would only be available to site authors with CSS knowledge. If it's as simple as adding a line(that you will provide, pretty please :)) to a file I just edit with a text editor, then that sounds like something I could be guided through without much trouble. 

I think I might just follow one of the above posters suggestion to start a new report to get an option included in about:config. I would've like something in about:config, but any kind of fix allowing personal choice is a welcome step, so I'll leave you guys to your work, and I thank you for the prompt replies and recent activity. 

There's a quite a few of us who've been eagerly waiting for some help on this for a while now, so it's nice to see some action.

Comment 75 Stevens 2009-03-31 15:39:29 PDT
There is very little chance that this will
be exposed in the UI as a preference, and given the presence of the CSS
attribute, not much reason to expose it in about:config.

Vlad, could you explain why there isn't much reason to expose it?  Surely, allowing the user to quickly edit this setting inside of Firefox is easier than forcing them to manually edit a CSS file and add 'rules' for it?  Opera has had such a config setting for ages, and no one has complained about it being there or has had cause to complain about filtering or non-filtering, since the option to turn it on or off is readily available.  It just seems like the dev team is really overcomplicating what could be a straightforward solution to satisfy the greatest amount of people -- a solution I daresay should have been offered to us at 3.0's launch.
Comment 76 crabby 2009-03-31 19:31:16 PDT
Stevens, I don't really disagree with your points, but we are going to get a way to disable filtering that should in the meantime be easy enough to guide people through. Once the CSS option is available for us, we can make the case for adding it to about:config. This bug report's been open for over a year so let's take this one step at a time.
Comment 77 Daniel 2009-04-01 00:37:02 PDT
I will have to excuse as well, I did not know, and so did not understand the stuff about userContent.css.
I now understand how it works, and yes, it sounds doable, but only for a small amount of people. However, there is also just a small amount of people that will use about:config, while with the css thing webmasters can seem to set the settings as wel. So to me, it looks fine now.
Comment 78 Robert Longson 2009-04-01 14:40:06 PDT
Created attachment 370513 [details] [diff] [review]

Not sure how I'd do CSS Background Images how can I determine what filter to use? Any ideas roc?

This does, however do html <img> elements.

For one img element add style="image-rendering: -moz-crisp-edges;"

For all img elements on a page/website add 

img { image-rendering: -moz-crisp-edges; } 

to the css stylesheet(s) for the pages.

To fix your browser to never filter add

img { image-rendering: -moz-crisp-edges; } 

to userContent.css (see

Other values are supported (see

Doesn't work on Linux (see comment 44 for why)
Not tested on Mac, although there is code for that platform.
Comment 79 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-04-01 15:30:48 PDT
(In reply to comment #78)
> Not sure how I'd do CSS Background Images how can I determine what filter to
> use? Any ideas roc?

PaintBackgroundLayer has aForFrame, why can't you just use its image-rendering property? Same for DrawBorderImage.

Other than that the patch looks great.
Comment 80 Vladimir Vukicevic [:vlad] [:vladv] 2009-04-01 17:16:53 PDT
Comment on attachment 370513 [details] [diff] [review]

Yep, what roc said for background images -- this looks fine though, but may as well get the background piece in at the same time.
Comment 81 Robert Longson 2009-04-02 01:32:15 PDT
I'm not sure what aForFrame is, but it doesn't seem to be the one I need. I tried 

background-image: url('animage.jpg');
image-rendering: -moz-crisp-edges;

And it had no effect on the background image. aForFrame is an nsBlockFrame and did not have the property.

I suspect we need a -moz-background-image-rendering CSS property, if so I'd rather do it in a follow-up bug and get dbaron or bz to help with it. If not where am I going wrong?
Comment 82 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-04-02 01:46:33 PDT
OK, "body" is a special case because the body background propagates to the viewport, so aForFrame is probably the root element's frame or something like that. Try it on a DIV.
Comment 83 Robert Longson 2009-04-02 02:30:32 PDT
Created attachment 370597 [details] [diff] [review]
address review comments

You are right. div works fine. 

What should I do about body?
I don't need reviews from any other module owners do I?
Comment 84 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-04-02 03:20:48 PDT
Comment on attachment 370597 [details] [diff] [review]
address review comments

If you set image-rendering on the root element, does that work for the body background? I expect so, and if so, then I don't think we need to do anything here. Body background propagation is quirky and I don't think we need to bend over backwards to make image-rendering fall in line.

I don't think you need any more reviews. This should be fine.

There are two more places we could use this property: <canvas> (to control the filtering used to scale the canvas when we render it) and <video> (similar).
Comment 85 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-04-02 03:21:50 PDT
... but we can do those in a separate patch. Thanks for doing this.

We should have a test here though. Should be easy enough to compare two test images, or an image to a reference made up of positioned DIVs.
Comment 86 Robert Longson 2009-04-02 03:30:27 PDT
background-image: url('animage.jpg');
image-rendering: -moz-crisp-edges;

doesn't work either. Neither does * { ... }

canvas already has a bug for this - bug 436932 

I'll work on some tests.
Comment 87 Robert Longson 2009-04-02 10:35:16 PDT
Created attachment 370684 [details] [diff] [review]

The images are green squares of different sizes a smaller red square. Zoom the smaller and compare it to the larger.
Comment 88 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-04-02 13:47:53 PDT
Bug 436932 is actually different. That controls how images are filtered when they're rendered into a canvas. image-rendering on the canvas element would control how the canvas is filtered when it's rendered to the screen.

We probably should do something to fix the root background situation (in a separate patch). nsLayoutUtils::GetGraphicsFilterForFrame should probably do something like nsCSSRendering::FindBackground to find the right style to use.
Comment 89 Vladimir Vukicevic [:vlad] [:vladv] 2009-04-02 14:03:30 PDT
Yep, we should do the canvas piece as well, but can do it separately from this bug.
Comment 91 Fabien Tassin 2009-04-06 13:42:45 PDT
If i'm not mistaken, this patch is the cause of the build failure i'm now experiencing:

g++ -o nsAlertsIconListener.o -c -I../../../dist/include/system_wrappers -include ../../../config/gcc_hidden.h -DOSTYPE=\"Linux2.6\" -DOSARCH=Linux -I../../../toolkit/components/build/ -I. -I. -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/necko -I../../../dist/include/alerts -I../../../dist/include/gfx -I../../../dist/include/imglib2 -I../../../dist/include/intl -I../../../dist/include/widget -I../../../dist/include   -I../../../dist/include/mozgnome -I/build/buildd/xulrunner-1.9.2-1.9.2~a1~hg20090406r26991+nobinonly/build-tree/mozilla/dist/include/nspr   -I/usr/include  -I/build/buildd/xulrunner-1.9.2-1.9.2~a1~hg20090406r26991+nobinonly/build-tree/mozilla/dist/sdk/include    -fPIC   -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions  -DORBIT2=1 -pthread -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gnome-vfs-module-2.0   -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12      -DMOZILLA_CLIENT -include ../../../mozilla-config.h -Wp,-MD,.deps/nsAlertsIconListener.pp nsAlertsIconListener.cpp
In file included from nsAlertsIconListener.cpp:42:
../../../dist/include/gfx/nsIImage.h:44:24: error: gfxPattern.h: No such file or directory
In file included from nsAlertsIconListener.cpp:42:
../../../dist/include/gfx/nsIImage.h:215: error: 'gfxPattern' has not been declared
../../../dist/include/gfx/nsIImage.h:215: error: expected ',' or '...' before 'aFilter'
../../../dist/include/gfx/nsIImage.h:285: error: 'gfxPattern' has not been declared
make[4]: *** [nsAlertsIconListener.o] Error 1

Full log:
Comment 92 Robert Longson 2009-04-06 14:21:45 PDT
Are you building xulrunner? The tinderboxes do build that and they seem to manage it so I'm not sure what your issue is.
Comment 93 Alexander Sack 2009-04-07 11:49:31 PDT
(In reply to comment #92)
> Are you building xulrunner? The tinderboxes do build that and they seem to
> manage it so I'm not sure what your issue is.

tinderboxes seem not to build all the gnome components that ubuntu currently builds on trunk.

opened bug 487262 for this regression.
Comment 94 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-04-07 12:08:23 PDT
There is a fix for that build failure in bug 487160.
Comment 95 - 2009-07-17 01:29:54 PDT
So apparently this "feature" has been fixed, but I don't know where I can turn off that hideous antialias in FF3.5.

Someone please tell me. And no, I'm not going to touch about:config.
Comment 96 sanjuro 2009-07-17 01:44:32 PDT
It seems it's coming with Gecko 1.9.2, which will be implemented in Firefox 3.6; we still need to be a little bit more patient:
Comment 97 Daniel 2009-11-05 23:34:48 PST
I have been using the alpha version of 3.6 (minefield) for at least over half a year now. And the image rendering works great.

However, today I noticed the beta of 3.6 is out, and there it is not fixed again! What is happening?
Comment 98 Robert Longson 2009-11-06 00:38:29 PST
I tried just now and it works perfectly fine in my 3.6 on Windows which I've admittedly built from source rather than installed like you have. The fix includes automatically run tests that would fail if any other fix broke it.
Comment 99 bavg1 2010-05-11 16:26:02 PDT
I am a person who does not know what half this things are, knows the bare basics of about:config and currently have this in Help!About Mozilla Firefox: "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100401 Firefox/3.6.3".

This issue really bugs me. I would like to have the option to change this but I don't. 

Would anyone be able to help me?
Comment 100 David B. 2010-05-11 16:41:23 PDT
As annoying as it is, you have to add an option to your chrome folder to turn the filtering off for all images right now.

Follow the instructions on:

The post by "jalonso"
Comment 101 Michal Čaplygin [:myf] 2010-05-11 17:14:35 PDT
To sum it up: 
1) Go to your Firefox profile folder ( )
2) Go to the "chrome" subfolder
3) Create "userContent.css" text file (or rename existing example)( )
4) Finally, add there following line and save.
img { image-rendering: -moz-crisp-edges; }
Comment 102 BoffinbraiN 2010-05-12 06:38:42 PDT
I would like to suggest that Gecko should always use nearest-neighbor (fast) interpolation when an image's resolution is larger than a certain threshold.

For example, Firefox really, really struggles when reducing the size of a 2000x2000 or larger JPEG image within a web page, and this is even more noticeable if CSS applies other positioning and scaling restrictions to the image or parent elements.

I'm guessing that the interpolating is happening every single time the page is re-rendered?  (I don't claim to know much about this)  If that's the case then maybe instead, Gecko could interpolate once, and cache the image result for the last requested dimensions?
Comment 103 d 2010-05-12 10:41:05 PDT
(In reply to comment #102)
> I would like to suggest that Gecko should always use nearest-neighbor (fast)
> interpolation when an image's resolution is larger than a certain threshold.
> For example, Firefox really, really struggles when reducing the size of a
> 2000x2000 or larger JPEG image within a web page, and this is even more
> noticeable if CSS applies other positioning and scaling restrictions to the
> image or parent elements.
> I'm guessing that the interpolating is happening every single time the page is
> re-rendered?  (I don't claim to know much about this)  If that's the case then
> maybe instead, Gecko could interpolate once, and cache the image result for the
> last requested dimensions?

Please file a new bug, this one has been resolved.
Comment 104 Karl Tomlinson (back Dec 13 :karlt) 2010-09-26 13:02:55 PDT
*** Bug 472981 has been marked as a duplicate of this bug. ***
Comment 105 Grant Galitz 2010-09-27 16:22:52 PDT
Feature trashed in certain cases by this bug:

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