FFe: Pixellated Images in Firefox/Opera due to incorrect EXTEND_PAD implementation in several video drivers

[Christian Göbel]

[Problem]
Upscaled images in Firefox (and Opera) look pixelated when zoomed, edges appear jagged.

[Discussion]
This is because firefox is using nearest-neighbor interpolation for upscaling. It would look better if bilinear filtering were used by Cairo, which requires EXTEND_PAD. However, EXTEND_PAD is not implemented very well in several video drivers, and Cairo is unable to distinguish drivers that have good implementations from ones with bad ones, so it is currently using a client-side fall back which is deemed too slow by the firefox developers.

Solving this requires updating each video driver to either implement EXTEND_PAD correctly or at least stop advertising it can do it when it really can't. Once this is done, cairo's client-side workaround can be removed and firefox can be updated to use EXTEND_PAD.

The proposed fixes are available (for jaunty and karmic) in the firefox-smooth-scaling PPA:
https://launchpad.net/~firefox-smooth-scaling/+archive/ppa

[Original Report]
With Ubuntu Hardy beta + latest updates (15th April 2008) I suffer from bad image rendering quality in Firefox.
To see the type of problem just open the attached screenshot and scale to 100%.

The images that are blurred are razor sharp if I do a right click -> view image so it is perhaps a problem related to
image scaling.

The problem appears only with my laptop - so perhaps it is not a bug in Firefox but elsewhere (X-windows??/intel-driver??).
The laptop has a 3-year old Centrino-Platform uses 915 intel driver and has a lcd monitor with 1400x1050 resolution.

The rendering problem appears independent of the Desktop-Effects are on/off. So it does not seem to be a problem with
compiz.

p.s. Also the text in the Gnome-terminal is somewhat blurred (compared with e.g. text in Gedit)
p.s. The same homepage renders nicely on my desktop computer with a 1280x1045 and the ati-driver.

Don't hesitate to ask for more information.

[Mardeg (mardeg)]

Proposal reference: http://primates.ximian.com/~federico/news-2005-11.html#moz-images

[Jo-hermans (jo-hermans)]

see bug 259672 and the patch in bug 296818

[Jim Kronebusch (jim-winonacotter)]

I referenced both the bug and the patch above. I have the mozilla source downloaded and the diff and have been trying to get this to work with patch, but get many errors. I would love to test if this patch would fix the pixmap problem. If anyone could post some quick steps I'll give it a whirl.

Thanks,
Jim Kronebusch

[Peter-vanderwoude (peter-vanderwoude)]

*** This bug has been marked as a duplicate of bug 296818 ***

[Bzbarsky (bzbarsky)]

I think this would be better addressed by a different solution from bug 296818. See bug 296818 comment 27.

[Bzbarsky (bzbarsky)]

To summarize that comment, I think it makes sense to have a preference for maximal size of the pixmap cache we end up with. Once we get there, we stop decoding new images that would take us over the cache size. The default can be either infinite or something large enough that not rendering images is better than trying to render them at that point. Deployments in low-resource situations (e.g. mobiles with no virtual memory, thin clients, etc) can set the preference as needed.

[Pavlov (pavlov)]

there is already a feature to disable caching image data as pixmaps (we don't cache pixmaps to X11).

MOZ_DISABLE_IMAGE_OPTIMIZE=1 firefox

[Pavlov (pavlov)]

not sure what people are hoping to get out of this bug. if it is "need feature to disable" then it is already there (dup of bug 336191).

If you want to be smarter about the way we allocate pixmaps, that could be done separately and in addition to what we already have.

[Jim Kronebusch (jim-winonacotter)]

Stuart, where is the MOZ_DISABLE_IMAGE_OPTIMIZE=1 firefox to be set? Do we just add that to about:config? I am not sure if I am misreading your statement in Comment 8 or not. If I monitor resources with xrestop, I can see system memory usage spike as a result of Firefox hitting an image intense website (see the example website in Comment 1). I looked at bug 336191, but still don't understand where to set the parameter and am not clear on if this patch is already present in current release firefox.

Boris, I think your suggestion for a user settable limit is a good idea. Is it possible to set so that once the limit is reached, older data is simply overwritten still allowing new data to be cached but not exceeding the limit?

Jim

[Bzbarsky (bzbarsky)]

> Stuart, where is the MOZ_DISABLE_IMAGE_OPTIMIZE=1 firefox to be set?

In the environment. Shell-agnostic command-line:

  env MOZ_DISABLE_IMAGE_OPTIMIZE=1 firefox

> not clear on if this patch is already present

It's present in the alphas of Firefox 3.

[Jim Kronebusch (jim-winonacotter)]

I have a build of firefox-granparadiso to test Federico's patch. I launched it at the command line with env MOZ_DISABLE_IMAGE_OPTIMIZE=1 firefox-granparadiso. Then I loaded the site http://www.carteretcountyschools.org/bms/teacherwebs/sdavenport/artgallery6.htm to see what happened and monitored with xrestop. Pixmap storage would hit very close to 25MB then be cleared and start over. This seemed to work very well. If I simply launched without the environment variable, Pixmap storage would climb to over 500MB+ by the time the page finished loading. This seems acceptable. Is this possible to do in Firefox 2.0.0.6 and is it possible to set the environment variable permanently?

I could still see a use for a user settable limit on storage, and the ability to set this environment variable in about:config to make it more user friendly. A settable discard timer would also be helpful. All of these would make Firefox more usable in low memory situations and still allow defaults to be set for performance in standard higher memory situations.

Thanks,
Jim

[Bzbarsky (bzbarsky)]

> Is this possible to do in Firefox 2.0.0.6

No. The support for this is in the new Thebes rendering code. I suppose you could try to backport that fix to branch, but...

> is it possible to set the environment variable permanently

In your own account? Of course. See your shell's documentation.

[Gavin McCullagh (gmccullagh)]

(In reply to comment #11)
> Then I loaded the site
> http://www.carteretcountyschools.org/bms/teacherwebs/sdavenport/artgallery6.htm

Something strikes me about the way firefox (or is it Gecko?) deals with this page. The real cause of this issue is that the page contains a number of massive images, which are embedded at small resolution in the page. We all know this is down to bad web page authoring, but obviously firefox has to deal with it. My laptop slows to a crawl loading this page.

Arguably the reason for the problems in that webpage is that firefox uses the video card to do the resizing -- therefore caching a huge quantity of image data which it will never actually display (unless the person chooses to view the image which is probably quite rare).

I realise the video card will do the resize more quickly, but if firefox resized the image in software, the X server's RAM usage would be fairly minimal as it would be caching the data which was actually needed. There is often a balance between cpu and ram usage, this seems to be one of them.

I would therefore be inclined to suggest an optional feature (particularly for remote X servers or low ram situations) where firefox would resize the image in software and send the resized pixmap to the X server. Perhaps this would only be used where the original image was above a certain size -- or where the display size was under some fraction of the image size (eg less than half the width and height).

The X server seems often to do a simple resample, rather than a resize, so I would expect firefox to do the same.

[Jim Kronebusch (jim-winonacotter)]

Gavin, maybe this is how non-gecko based browsers are handling this and possibly why they are not affected in the same fashion.

Boris, Stuart, is this possible?

[Bzbarsky (bzbarsky)]

Storing images at the original size is a pretty long-standing imagelib design decision. You might want to read the various existing bugs that discuss that behavior.

[Norbert-notz (norbert-notz)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9b4) Gecko/2008030318 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9b4) Gecko/2008030318 Firefox/3.0b4

Implement Bug 381661 (image filtering) for Linux

Reproducible: Always

Steps to Reproduce:
.
Actual Results:
Images in zoomed pages looks ugly.

Expected Results:
Images in zoomed pages look like in Firefox Windows build.

[TheQuickBrownFox (theprash)]

Any chance of this getting fixed by FF3 final? At least as an about:config setting? Us Linux users are feeling a little left out despite all the talk of equality across platforms.

[Vladimir Vukicevic (vvuk)]

(In reply to comment #1)
> Any chance of this getting fixed by FF3 final? At least as an about:config
> setting? Us Linux users are feeling a little left out despite all the talk of
> equality across platforms.

Talk to your distro provider then; the lack of the needed functionality in X is beyond our control.

[Christian Göbel (christiangoebel)]

Binary package hint: firefox-3.0

With Ubuntu Hardy beta + latest updates (15th April 2008) I suffer from bad image rendering quality in Firefox.
To see the type of problem just open the attached screenshot and scale to 100%.

The images that are blurred are razor sharp if I do a right click -> view image so it is perhaps a problem related to
image scaling.

The problem appears only with my laptop - so perhaps it is not a bug in Firefox but elsewhere (X-windows??/intel-driver??).
The laptop has a 3-year old Centrino-Platform uses 915 intel driver and has a lcd monitor with 1400x1050 resolution.

The rendering problem appears independent of the Desktop-Effects are on/off. So it does not seem to be a problem with
compiz.

p.s. Also the text in the Gnome-terminal is somewhat blurred (compared with e.g. text in Gedit)
p.s. The same homepage renders nicely on my desktop computer with a 1280x1045 and the ati-driver.

Don't hesitate to ask for more information.

[Christian Göbel (christiangoebel)]

O.k. the problem with blurred fonts in the Gnome-terminal seems to be bug #190848 - so this is a different issue.

Reading through the Ubuntu-forums I got a hint, that the blurred images in Firefox may have something to do with zooming.
So if Firefox preserves the zooming-level that has been used in the last session this might lead to the impression that there is
a rendering problem. I am gonna check this evening.

[Christian Göbel (christiangoebel)]

Effectively the images are o.k. when the page is viewed without zoom.
Perhaps Firefox should set the zoom-level to 100% when restarted?

I also compared the rendering quality (when zoomed) with Firefox 3.0 beta5 on Windows XP and it appears that on Windows the images are blurred but it is less disturbing since on Windows the images are not pixeled.

Probably the bug description should changed to:
"Images in Firefox are extremely pixeled when zoomed"

To reproduce:
1) open Firefox, go to ubuntuforums: http://ubuntuforums.org/
2) type Str++ twice to zoom
3) look at the "ubuntu forums logo"

[John Vivirito (gnomefreak)]

The bug about the zoom has already been reported in Launchpad just cant recall bug number, If i find it while going through email today ill mark it as such.

[John Vivirito (gnomefreak)]

I will look for it in morning some more it should be in my bugs list somewhere.

[John Vivirito (gnomefreak)]

The bug i thought was the same was bug #182038 but seems to be a different issue with zoom allk together. PLease look at bug and let me know if you are seeing the same issue as on that bug.

[Alexander Behringer (alexander-behringer-deactivatedaccount)]

I think there are two separate problems with zoomed images:

The first thing is, that in firefox 2.x only the text size was increased (and all objects with related size) when "zooming" (e.g. with ctrl+"+"). In firefox 3 however the image size is increased as well. But its possible to disable zooming of images via the menu (View -> Zoom -> Zoom Text Only). Maybe the default of that option should be changed.

The other thing is, that zoomed images are apparently nearest-neighbor interpolated, which indeed does not look very nice.
However shrinked images (e.g. via ctrl+"-") look good.
So i guess (real) interpolation is only enabled for shrinked images. Maybe for performance reasons?

[Christian Göbel (christiangoebel)]

@ John Vivirito: I tried most of the example of bug #182038 and I couldn't reproduce a single example. Perhaps I don't have the described bugs because I have a intel-centrino graphic card?

The phenomenon I reported as a bug seems only be related to the way images are zoomed / interpolated. Is there a known reason why this is done differently under WindowsXP and under Linux?

[Christian Göbel (christiangoebel)]

Can anybody reproduce/confirm this bug? Should I provide additional information?

[Federico-ximian (federico-ximian)]

Where in the code should this be implemented? What is needed from X?

[Federico-ximian (federico-ximian)]

To wit: nothing should be needed from X; GTK+ can already do beautiful scaling for you :)

[Mr_Miyagi (david-wargert)]

I've had the same problem and it seems to be related to the zoom, when I reset it the images were rendered correctly.
The difference between the rendering on linux compared to windows could be because of this:
http://blog.vlad1.com/2008/03/18/a-little-more-cairo-just-for-you/

"Linux users will have to wait a little longer to get higher quality image scaling; as we now rely on the X server to do image compositing through the Render extension, we'll have to wait until the pixman patches are integrated into the X server. I'm hoping that will happen in time for the next X.org release."

[Dao (dao)]

*** Bug 431990 has been marked as a duplicate of this bug. ***

[John Vivirito (gnomefreak)]

Christian Göbel wrote:
> ** Changed in: firefox-3.0 (Ubuntu)
> Status: Incomplete => Confirmed
>
Added tags mt-eval and mt-upstream.
Can someone please look for this bug in mozilla's bugzilla to see if it
has already been reported and what the status is, If you find one or
more that look like it is the bug please post the link on this bug
report and we will take a look at it and add it as needed. Incase you do
find it and are sure its the same please add it to tasks or post link here.
I think we have enough info on this bug to triage upstream but added
mt-eval in case someone on MT can think of other info needed but looks
right to me.

--
Sincerely Yours,
     John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

[ubuntu_demon (ubuntu-demon)]

I am also affected. I have an intel 945 graphics chipset. I have attached my lspci -nn.

This issue is known upstream :
https://bugzilla.mozilla.org/show_bug.cgi?id=411831

I discovered the upstream bug because it was listed between the known issues for Firefox RC2 in the Linux and Unix section as a problem with the nvidia driver :
http://www.mozilla.com/en-US/firefox/3.0rc2/releasenotes/#issues

I found a comment which is potentially interesting :
from https://bugzilla.mozilla.org/show_bug.cgi?id=411831#c101 :

[quote=Luke Hutchison ]
If anybody is wondering why this bug magically fixed itself in their distro
recently, it's because Ubuntu and Fedora have inverted the default behavior of
the XAANoOffscreenPixmaps option.

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/182038/comments/111

In case you're trying to debug this, you may need one of the following options
to bring back the broken behavior:

        Option "XAANoOffscreenPixmaps" "false"
        Option "XAAOffscreenPixmaps" "true"

Seems like sweeping things under the rug to me :o)
[/quote]

[Alexander Sack (asac)]

On Sat, Jun 07, 2008 at 07:41:36AM -0000, ubuntu_demon wrote:
> I am also affected. I have an intel 945 graphics chipset. I have
> attached my lspci -nn.
>
> This issue is known upstream :
> https://bugzilla.mozilla.org/show_bug.cgi?id=411831

vlad states that this is a X issue. However, X upstream wont fix XAA
so this probably is a dead end bug. Lets hope that EXA will be
everywhere soon.

 - Alexander

[moenchmeyer (rm-anracon)]

(In reply to comment #2)
> (In reply to comment #1)
> > Any chance of this getting fixed by FF3 final? At least as an about:config
> > setting? Us Linux users are feeling a little left out despite all the talk of
> > equality across platforms.
>
> Talk to your distro provider then; the lack of the needed functionality in X is
> beyond our control.
>

Does this mean that X could provide the necessary functionality but that it is the fault of the distro provider that the distro's X server implementation lacks the required properties?

Or is a basic feature missing in the xorg X-server itself?

[Federico-ximian (federico-ximian)]

I don't really know where in the code Mozilla scales the images, but if it needs to do that on Linux, it seems that it could use the gdk_pixbuf_scale*() family of functions very easily. Use GDK_INTERP_BILINEAR which is very nice and fast.

[Federico-ximian (federico-ximian)]

The documentation is here:
http://library.gnome.org/devel/gdk-pixbuf/stable/gdk-pixbuf-scaling.html

I'll be happy to assist anyone who wants to implement this.

[Vladimir Vukicevic (vvuk)]

Mozilla doesn't scale the images at all -- we hand off the image and a transform to RENDER, which needs to do the scaling. The issue is that the version of pixman that's currently shipped with all X servers doesn't implement EXTEND_PAD, which we need to get correct behaviour at image edges.

[Marin-krkac (marin-krkac)]

I was slightly annoyed by this not working so I tried to see what would happen if I uncommented the two special cases for bug 324698 in gfx/src/thebes/nsThebesImage.cpp (at lines ~573 and ~785). This means that the default case, with EXTEND_PAD, is used in the switch statement.

I compiled Firefox (the official Mozilla version) with --enable-system-cairo on Ubuntu 8.04, and it worked. I've been using it like this since RC1 and I haven't noticed any problems. I also tried zooming in on the IE 8 Beta page and it looks the same as the image on your blog.

If I'm not missing something obvious here, could you please create an (temporary?) official patch that could be used to enable this in the packages of the distributions for which it works?

Packages on my system:
xserver-xorg-core
2:1.4.1~git20080131-1ubuntu9.2

libpixman-1-0
0.10.0-0ubuntu1

libcairo2
1.6.0-0ubuntu2

[21-vingtetun (21-vingtetun)]

*** Bug 559871 has been marked as a duplicate of this bug. ***

[Zweinberg (zweinberg)]

I am not realistically going to fix this anytime soon.

[Bugreply-20-herbalizer (bugreply-20-herbalizer)]

Tom Jaeger's fix from launchpad is working perfectly on Ubuntu 10.04. - Is there any specific reason why this isn't being added to firefox?

[Henri Sivonen (hsivonen)]

Nominating for 1.9.3. Without this patch, Firefox scales images on Linux in a substantially uglier way than Opera or Chrome. I've been running with this patch for weeks now on Karmic with no ill effects.

[Rogi (rogi)]

(In reply to comment #65)
> Tom Jaeger's fix from launchpad is working perfectly on Ubuntu 10.04. - Is
> there any specific reason why this isn't being added to firefox?

There are some steps needed to get this patch work correctly with all current linux graphic-drivers. See here for more infos: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/217908

[Rogi (rogi)]

Nouvea has small issue with fix, see my attachment with kaffeine homepage-screenshot. It happens with other pages too, wikipedia.org, openstreetmap.org, start.ubuntu.com start.ubuntu.com/10.04/Google/ for example. No issues on the same system with nvidia proprietary driver.

[longsonr (longsonr)]

*** Bug 571853 has been marked as a duplicate of this bug. ***

[NoBugs! (luke32j)]

I noticed when Firefox updated to the normal version, it was called Firefox. Then when it updated to the firefox-smooth-scaling version, it was called "Namoroka", and it also sends "Namoroka" as user-agent instead of "firefox". This causes compatibility problems for some sites, similar to this bug:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/397211

[Tom Jaeger (thjaeger)]

The mozilla foundation does not allow the use of the firefox name and
logo when shipping a modified version of firefox, so this is both
expected and unavoidable.

On 06/30/2010 08:44 PM, NoBugs! wrote:
> I noticed when Firefox updated to the normal version, it was called Firefox. Then when it updated to the firefox-smooth-scaling version, it was called "Namoroka", and it also sends "Namoroka" as user-agent instead of "firefox". This causes compatibility problems for some sites, similar to this bug:
> https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/397211
>

[Miroslav Hadzhiev (xtigyro)]

I've used Tom Jaeger's fix since Ubuntu 8.10 and it's working flawlessly.
I've Ati Mobility X1600 (OSS radeon driver in use).
And on my old computer nVDIA video card on board (and nVIDIA proprietary driver in use).

No problems at all.

[Astralstorm (astralstorm)]

Well, the Ubuntu bug is wrt Hardy Heron, which is really outdated by now, the problem has been fixed in i915 driver a long time ago.
Also, pixman software scaling performance has improved a lot since with addition of SSE and SSE2 scaling - some versions back.

Please do review and apply the patch finally and stop holding Linux Firefox in 2009. This bug is forcing high resolution screen and Linux users to rebuild patched Firefox.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

(In reply to comment #70)
> Well, the Ubuntu bug is wrt Hardy Heron, which is really outdated by now, the
> problem has been fixed in i915 driver a long time ago.
> Also, pixman software scaling performance has improved a lot since with
> addition of SSE and SSE2 scaling - some versions back.
>
> Please do review and apply the patch finally and stop holding Linux Firefox in
> 2009. This bug is forcing high resolution screen and Linux users to rebuild
> patched Firefox.

Ubuntu just upgraded Hardy to Firefox 3.6.x and will hopefully finish out the 3 yr support on that branch. But regardless, we're using in-source cairo now, so we shouldn't be holding anything back.

[Elvanor2007 (elvanor2007)]

I want to add that this problem also causes graphical artefacts on some sites even without manually zooming. See

http://playground.kameleoon.net/engine/image_scaling.html

Under Linux, Firefox 3.6.8 will display a red block next to the gradient because the image is not correctly scaled (look at the attached screenshot).

Under Chrome or with a patched Firefox using EXTEND_PAD, it looks as it should.

Therefore please really consider applying this patch for Firefox 4 final; it causes artefacts with perfectly valid HTML / CSS for Linux Firefox users.

[Elvanor2007 (elvanor2007)]

Created attachment 465688
Screenshot of a valid web page, with an artefact on FF under Linux

[Graham Perry (misc-noisp)]

Is there anything stopping this patch being applied?

[Karlt (karlt)]

I think the server version check is needed.
(I wouldn't bother with a cairo version check.)

Might as well use EXTEND_PAD for upscaling with server >= 1.7.
I was thinking something like

 gfxPattern::GraphicsExtend gfxContext::PreferredExtend().

[Kurosawa Takeshi (takenspc)]

(In reply to comment #75)
> I think the server version check is needed.
> (I wouldn't bother with a cairo version check.)
>
> Might as well use EXTEND_PAD for upscaling with server >= 1.7.
> I was thinking something like
>
> gfxPattern::GraphicsExtend gfxContext::PreferredExtend().

cairo seems already to do something like it,

http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-xlib-display.c#339

... and fallbacks if the server is buggy, doesn't it?

http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-xlib-surface.c#1591

[Karlt (karlt)]

(In reply to comment #76)
> cairo seems already to do something like it,
>
> http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-xlib-display.c#339

Yes, we need to match those buggy_pad_reflect server version tests exactly.

> ... and fallbacks if the server is buggy, doesn't it?

Right. But the fallback that cairo needs to do is quite disastrous to performance. It will read back the image (and the destination, if there is an alpha channel in the image) from the server to software scale and then return to the server.

I assume it's possible to do some fancy FILTER_NEAREST only for the source-image-pixel-width outer border and FILTER_BILINEAR for the interior of the image,
but I'm not sure it's worth it just for older servers.

Simplest is probably to keep the old behavior for older servers, but fix up things with EXTEND_PAD/FILTER_BILINEAR for newer servers.

[Eric-rannaud (eric-rannaud)]

>> ... and fallbacks if the server is buggy, doesn't it?
>
> Right. But the fallback that cairo needs to do is quite disastrous to
> performance. It will read back the image (and the destination, if there is an
> alpha channel in the image) from the server to software scale and then return
> to the server.

This is FUD. Many apps do purely software scaling with reasonable performance. Google Chrome was, at least until recently (and probably still is). And it's still faster than current Firefox with in-server NEAREST.

Images are small wrt the available memory bandwidth. The majority of images on the web render to bitmaps that are way less than 1 or 2 MB (4 Bytes per pixel). Bandwidth is over 1GB/s on any computers bought since 2003.

Scaling images is cheap. The 90s are over.

[Graham Perry (misc-noisp)]

So the quickest, simplest way forward is to implement the patch, rely on cairo for the fallback and accept the performance hit due software scaling on older servers, then in future (if the need should arise) create a fallback to the old behaviour?

[Karlt (karlt)]

These older servers are not very old (~ Oct 2009),
and the performance hit would be more due to readback than software scaling.
(EXTEND_NONE is often done is software even server-side.)
(I don't know what Chrome does but maybe its doing its compositing client-side, so there's no need to read back.)

[Hrvoje Nikšić (hniksic)]

For testing the performance of cairo software scaling with readback, and possible comparison with chrome and hardware-enabled scaling in firefox, here is an example web page that embeds ten large images scaled to a smaller size:

http://www.flickr.com/groups/highres_favorites/discuss/72157611461261406/

[Karlt (karlt)]

That's great thanks, Hrvoje.

Since bug 572680, the code has moved back to thebes (gfxDrawable.cpp), so your reviewed patch would also apply there (and we don't need anything like gfxContext::PreferredExtend()).

[Karlt (karlt)]

Oh, sorry, it's Tom's patch.

[Kurosawa Takeshi (takenspc)]

Created attachment 469348
Updated version of Tom's patch

Updated version of Tom's last patch with some #ifdefs and minor modifications.

[Kurosawa Takeshi (takenspc)]

Created attachment 469353
honor cairo version in tree

This is needed for main patch.

The revision of cairo in tree is 12d521df8acc483b2daa844d4f05dc2fe2765ba6,
thus the version of cairo is 1.9.5.

* http://hg.mozilla.org/mozilla-central/rev/f236632a9747
* http://cgit.freedesktop.org/cairo/tree/cairo-version.h?id=12d521df8acc483b2daa844d4f05dc2fe2765ba6

[Micah Gersten (micahg)]

Marking this Triaged. Looks like this will hit Firefox trunk soon.

[Micah Gersten (micahg)]

This won't be fixed in xulrunner-1.9 since it's EOL.

[Dao (dao)]

Is this ready to land?

[Lovyagin (lovyagin)]

What is the problem to implement this https://launchpad.net/~firefox-smooth-scaling/+archive/ppa patch for example? I've just looked at firefox 4 beta and images still looks pixelated...

[Astralstorm (astralstorm)]

lovaygin:
Those patches are for older versions of firefox.
The patches included in this bug (last two) apply to latest firefox betas and work well, superseding those old ones.
They haven't been applied yet to the development tree.

Of course, you need either cairo 1.9.2 or to use the included one with firefox and run on Xorg 1.7 to see the improvement, which is great. Doesn't even compare with cairo 1.8.x and older EXTEND_PAD patches.

(Tested on ATI closed driver and Radeon open driver.)

Seems to me this is ready to land.

[Roc-ocallahan (roc-ocallahan)]

(In reply to comment #80)
> (I don't know what Chrome does but maybe its doing its compositing client-side,
> so there's no need to read back.)

That is indeed what Chrome does.

[Lovyagin (lovyagin)]

Szkodziński:
Do you going to say that I need those new patches and new cairo to compile and run new version of firefox or it's better for 3.6.x too? Do I need to patch xulrunner too as I did with older patch from launchpad?

So, no chance that firefox will runs well without pain of patching each update in a near future? (Well, I have NVidia and use closed driver.)

[Ehsan-mozilla (ehsan-mozilla)]

Created attachment 473677
Part 3: disable a failing reftest on linux

This reftest fails on Linux with this patch because now we do bilinear filtering on Linux like everywhere else.

[Ehsan-mozilla (ehsan-mozilla)]

http://hg.mozilla.org/mozilla-central/rev/89816be9e164
http://hg.mozilla.org/mozilla-central/rev/c08cbc8f4fa6
http://hg.mozilla.org/mozilla-central/rev/49291ab908cc

[甘露 (Lu Gan) (rhythm-gan)]

I downloaded the "Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre" nightly, it works greatly when zooming.
My configuration:
Arch Linux current (xorg-server 1.8.1.902 xf86-video-ati 6.13.1 cairo 1.8.10)
ATI radeon V3200 on a old IBM T43P

[olive (olivier.fraysse)]

mozilla-bugs #422179 is "RESOLVED FIXED"

2010-09-10 04:43 PDT

[NoBugs! (luke32j)]

Firefox zoom ppa isn't up-to-date for 10.04.
https://launchpad.net/~firefox-smooth-scaling/+archive/ppa
I'd update to Firefox 4, but some addons aren't available...

[Oibaf (oibaf)]

This should be fixed in openSUSE 11.4 which ships Firefox 4.

[Oibaf (oibaf)]

Fixed in natty with firefox 4.