white lines in image on first load

RESOLVED FIXED

Status

()

Core
Layout: Images
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: Brian Ryner (not reading), Assigned: Brian Ryner (not reading))

Tracking

({fixed-aviary1.0, fixed1.7.5})

Trunk
x86
Linux
fixed-aviary1.0, fixed1.7.5
Points:
---
Bug Flags:
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Assignee)

Description

14 years ago
When the firebird start page first loads (or shift+reload), I see two white
lines in the screen shot image on the right.  I'm just guessing by putting this
in Image: Layout; I'm sure it'll turn out to be some insane twip rounding bug.
(Assignee)

Comment 1

14 years ago
Created attachment 133659 [details]
screen shot of problem
(Assignee)

Comment 2

14 years ago
Created attachment 133663 [details]
reduced testcase

Here are things I found are critical to triggering the bug:

- the transitional doctype, presumably to trigger quirks mode
- the h3 text above the image
- the height on the image (causing it to be scaled)
- the image loading from the server (presumably to slow down the image load so
that we don't draw all of it at once)

any ideas?
(Assignee)

Comment 3

14 years ago
Created attachment 133667 [details]
log of calls to nsImageGTK::Draw() when bug happens

This is from enabling TRACE_IMAGE_ALLOCATION in nsImageGTK.cpp. (I'm still
trying to understand why the destination y coordinate is an increasing negative
number)
(Assignee)

Comment 4

13 years ago
Created attachment 156072 [details] [diff] [review]
patch

This should make things better.  The problem is that when we get new decoded
rows in the source image, we don't necessarily invalidate as many rows onscreen
as we need to (for scaled images).  This patch makes us invalidate from (N-1 *
F) to (N+1 * F) when row N is received (F is the scaling factor).  tor tells me
this is a mathematical bound on the nearest-neighbor scaling function used in
XlibRectStretch (nsImageGTK.cpp), so it should cover any row that could
possibly be drawn using the newly-decoded source row.  I tested this and didn't
find any Tp regressions.
(Assignee)

Updated

13 years ago
Attachment #156072 - Flags: superreview?(tor)
Attachment #156072 - Flags: review?(pavlov)

Updated

13 years ago
Attachment #156072 - Flags: review?(pavlov) → review+
(Assignee)

Comment 5

13 years ago
Created attachment 157167 [details] [diff] [review]
merged to the trunk
(Assignee)

Updated

13 years ago
Attachment #156072 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #157167 - Flags: superreview?(tor)

Updated

13 years ago
Attachment #157167 - Flags: superreview?(tor) → superreview+
(Assignee)

Updated

13 years ago
Attachment #156072 - Flags: superreview?(tor)
(Assignee)

Comment 6

13 years ago
Comment on attachment 157167 [details] [diff] [review]
merged to the trunk

requesting 1.7 branch approval
Attachment #157167 - Flags: approval1.7.3?
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
Flags: blocking-aviary1.0+

Comment 7

13 years ago
Comment on attachment 157167 [details] [diff] [review]
merged to the trunk

a=mkaply
Attachment #157167 - Flags: approval1.7.x? → approval1.7.x+
(Assignee)

Comment 8

13 years ago
checked in on aviary branch and 1.7 branch
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed-aviary1.0, fixed1.7
Resolution: --- → FIXED
(Assignee)

Comment 9

13 years ago
should have been fixed1.7.x, not fixed1.7
Keywords: fixed1.7 → fixed1.7.x
You need to log in before you can comment on or make changes to this bug.