Closed Bug 487996 Opened 16 years ago Closed 16 years ago

Full page zooming out creates an ugly rectangle around the image

Categories

(Core :: Graphics, defect, P2)

All
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 468496

People

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

References

()

Details

(Keywords: regression, testcase)

Attachments

(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% http://img13.imageshack.us/img13/9823/problematj.jpg Image with 100% zoom http://img83.imageshack.us/img83/6883/nproblem.jpg Reproducible: Always Steps to Reproduce: 1. Allow full page zoom 2. Zoom out using Ctrt+- or Ctrl+MouseWheelDown 3. 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 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fbae114d6133&tochange=dcec193ba5d7 I suppose this is a regression from bug 458487?
Status: UNCONFIRMED → NEW
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?
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: