Last Comment Bug 222901 - white lines in image on first load
: white lines in image on first load
Status: RESOLVED FIXED
: fixed-aviary1.0, fixed1.7.5
Product: Core
Classification: Components
Component: Layout: Images (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Brian Ryner (not reading)
:
Mentors:
http://www.mozilla.org/products/fireb...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-19 17:17 PDT by Brian Ryner (not reading)
Modified: 2004-09-09 14:44 PDT (History)
3 users (show)
bryner: blocking‑aviary1.0+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
screen shot of problem (51.09 KB, image/png)
2003-10-19 17:17 PDT, Brian Ryner (not reading)
no flags Details
reduced testcase (249 bytes, text/html)
2003-10-19 17:51 PDT, Brian Ryner (not reading)
no flags Details
log of calls to nsImageGTK::Draw() when bug happens (2.63 KB, text/plain)
2003-10-19 19:16 PDT, Brian Ryner (not reading)
no flags Details
patch (3.17 KB, patch)
2004-08-13 16:23 PDT, Brian Ryner (not reading)
pavlov: review+
Details | Diff | Splinter Review
merged to the trunk (3.98 KB, patch)
2004-08-27 10:36 PDT, Brian Ryner (not reading)
tor: superreview+
mozilla: approval1.7.5+
Details | Diff | Splinter Review

Description Brian Ryner (not reading) 2003-10-19 17:17:18 PDT
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.
Comment 1 Brian Ryner (not reading) 2003-10-19 17:17:44 PDT
Created attachment 133659 [details]
screen shot of problem
Comment 2 Brian Ryner (not reading) 2003-10-19 17:51:24 PDT
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?
Comment 3 Brian Ryner (not reading) 2003-10-19 19:16:15 PDT
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)
Comment 4 Brian Ryner (not reading) 2004-08-13 16:23:46 PDT
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.
Comment 5 Brian Ryner (not reading) 2004-08-27 10:36:13 PDT
Created attachment 157167 [details] [diff] [review]
merged to the trunk
Comment 6 Brian Ryner (not reading) 2004-08-28 16:48:21 PDT
Comment on attachment 157167 [details] [diff] [review]
merged to the trunk

requesting 1.7 branch approval
Comment 7 Mike Kaply [:mkaply] 2004-09-07 11:22:36 PDT
Comment on attachment 157167 [details] [diff] [review]
merged to the trunk

a=mkaply
Comment 8 Brian Ryner (not reading) 2004-09-07 11:48:57 PDT
checked in on aviary branch and 1.7 branch
Comment 9 Brian Ryner (not reading) 2004-09-09 14:44:02 PDT
should have been fixed1.7.x, not fixed1.7

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