Closed Bug 487996 Opened 13 years ago Closed 12 years ago

Full page zooming out creates an ugly rectangle around the image


(Core :: Graphics, defect, P2)






(Reporter: ra.ravi.rav, Assigned: jrmuizel)




(Keywords: regression, testcase)


(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3

I use Firefox and it looks that it has got some strange problem with full page zooming.

When I zoom out images develop a blackish outline around them which looks ugly. However on zooming >= 100% the problem disappears.

I have tried reinstalling Firefox. creating new user profiles, deleting all Firefox related data including installation itself, but the problems persists.

Image with zoom < 100%

Image with 100% zoom

Reproducible: Always

Steps to Reproduce:
1. Allow full page zoom
2. Zoom out using Ctrt+- or Ctrl+MouseWheelDown
Actual Results:  
A blackish border develops around the image.

Expected Results:  
The image though a bit distorted, but shouldn't have a border around itself.

This happens will most of sites, but not with every image. Like in Gmail the logo won't develop such rectangle on zooming out.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090412 Shiretoko/3.5b4pre

Not reproducible on Windows XP, so this could be Linux only.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.9.1 Branch
Regression range:
ok:  2008-11-04-02 fbae114d6133
fail: 2008-11-05-02 dcec193ba5d7 

I suppose this is a regression from bug 458487?
Component: Layout → Layout: Images
Ever confirmed: true
Keywords: regression, testcase
QA Contact: layout → layout.images
Hardware: x86 → All
Version: 1.9.1 Branch → Trunk
Can't reproduce on OSX either, so it looks to be linux only.
I reproduce it in my Linux VM. Almost certainly a gfx bug ... Vlad, can I persuade you to get one of your people to look at it?
Yep -- Jeff, could you take a look at this?  The patch that's to blame is large, but given that it doesn't happen on win32 or OSX, I'm guessing that just following the path down into cairo should tell us what's going on.
Flags: blocking1.9.1+
Priority: -- → P2
Component: Layout: Images → GFX: Thebes
QA Contact: layout.images → thebes
Assignee: nobody → jmuizelaar
This looks like an extend pad problem...
In fact it looks like it's by design. We explicitly don't use EXTEND_PAD with xlib surfaces. It is not clear to me why.
Because most drivers are broken with EXTEND_PAD, so cairo falls back to insanely slow fallback where it fetches bits from the X server, composites locally with pixman, then sends them back. You know, there have been threads about this on the cairo list for ages.

We should be falling back to FILTER_NEAREST, but we know that that doesn't always fix bleed at image edges. We'll probably have to leave this unfixed for now.
Was it just chance that this didn't happen before your image snapping patch, Rob?
Probably. There were other bugs that that patch did fix. Without EXTEND_PAD or something equivalent, there are always going to be bugs here, we can only move them around between different testcases.
Flags: blocking1.9.1+ → blocking1.9.1-
Suggest marking this a duplicate of bug 468496, treat that as the canonical "we need EXTEND_PAD to work" bug?
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 468496
You need to log in before you can comment on or make changes to this bug.