Off-by-one pixel when scrolling vertically



Core Graveyard
16 years ago
4 years ago


(Reporter: Jim Moe, Assigned: mkaply)




Firefox Tracking Flags

(Not tracked)




(4 attachments)



16 years ago
User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3a) Gecko/20021210
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3a) Gecko/20021210

Text: When scrolling up or down, the renedered text can sometimes be missing a
line one pixel thick, or have an line one pixel duplicated.
Images: The appearance of one or more horizontal white lines one pixel thick.
Re-load: The page usually scrolls up (towards the top pf a page) one pixel when
a page is re-loaded. This does not always happen. (Obviously not when at the top
of a page.)

Reproducible: Always

Steps to Reproduce:
1. Pick a site
2. Scroll down a little bit.
3. Scroll up.

Actual Results:  
  Some lines of text have an extra line in them making the line look taller than
others. Other lines have a line missing.
  Some images have white horizontal lines. The placement and quantity of the
lines varies.

Expected Results:  
No extra or missing lines.
The rendered page should not shift vertically when it is re-loaded and the
content has not changed.

  I do not recall when I first noticed this; somewhere around v1.0, maybe
earlier. It has been common in v1.1 and v1.2, less so in v1.3a.
  Selecting the mis-rendered text forces a re-rendering which corrects the
blemish. Covering and uncovering an image gets rid of the white lines.
  The problem is more likely to occur toward the bottom of the page.

Comment 1

16 years ago
Created attachment 112374 [details]
Example of text with a missing line.

Comment 2

16 years ago
Created attachment 112375 [details]
Example of an image with white lines.
Whiteboard: DUPEME
This could be an OS/2 only issue. I haven't seen this on Linux for a long time.

Comment 4

16 years ago
Created attachment 115116 [details]
Second example of off-by-one

  Another aspect of this defect is how tables are displayed. Every third or
fourth line has an extra space in it.
  The left half of the image shows the re-paint after that section had been
covered by another application. The right half is how it was originally
displayed (and desired). It is normal for the converse to occur.

Comment 5

15 years ago

*** This bug has been marked as a duplicate of 171282 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 6

15 years ago
  The text aspect of this problem has a solution: install the Freetype font
smoothing software (technology preview) offered by Innotek (
Besides doing a very nice job of artfully blurring text, the problems I had with
font rendering have completely disappeared.
  Another benefit relates to scrolling with a mouse. Scrolling down would
initially have a jump up before continuing down. The further down a page, the
larger the jump. This behavior has disappeared as well.
Resolution: DUPLICATE → ---
Moving to Gfx:OS/2.  I suspect the main problem is this commented-out code in
nsDeviceContextOS2::Init, which should replace the code that's uncommented:

  // make p2t a nice round number - this prevents rounding problems
//  mPixelsToTwips = float(NSToIntRound(float(NSIntPointsToTwips(pt2t)) /
//  mTwipsToPixels = 1.0f / mPixelsToTwips;
  mTwipsToPixels = ((float)dpi) / (float)NSIntPointsToTwips(72);
  mPixelsToTwips = 1.0f / mTwipsToPixels;

This would certainly cause problems of this type.
Assignee: other → mkaply
Component: Layout → GFX: OS/2


15 years ago
OS: other → OS/2

Comment 9

15 years ago
Created attachment 130782 [details] [diff] [review]

I agree with dbaron. We should be rounding.

I also took this opportunity to cleanup the corresponding code in printing as


15 years ago
Attachment #130782 - Flags: review?(pedemont)


15 years ago
Attachment #130782 - Flags: review?(pedemont) → review+

Comment 10

15 years ago
Comment on attachment 130782 [details] [diff] [review]

sr=blizzard (platform specific)
Attachment #130782 - Flags: superreview+
Attachment #130782 - Flags: approval1.5+
Attachment #130782 - Flags: approval1.4.x+

Comment 11

15 years ago
Fixed on trunk and branch
Last Resolved: 15 years ago15 years ago
Keywords: fixed1.4.1
Resolution: --- → FIXED
ahm, this could break printing on OS/2 a la bug 211092

Comment 13

15 years ago
I'll do some more testing tomorrow.

It's easy not to do the rounding for printing on OS/2 since we follow different

Unfortunately I compared my reslts to Windows to see if I was printing correct.
Oops :)
Just test the testcases in bug 211092 to make sure that 100mm boxes print as
100mm, etc.

Comment 15

15 years ago
You are correct sir.

I took out the rounding in the printing section.
This is dupe of bug #94739 and is NOT FIXED, I think...
Product: Core → Core Graveyard


4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.