Closed Bug 120918 Opened 23 years ago Closed 23 years ago

1 pixel shift when rendering / scrolling (96DPI)

Categories

(Core Graveyard :: GFX, defect, P2)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: tnahm, Assigned: kmcclusk)

References

(
URL
)

Details

(Keywords: topembed+, Whiteboard: [adt3])

Attachments

(3 files)

Screen shot of image that shows problem
33.21 KB, image/jpeg
Details
Possible fix
835 bytes, patch
dcone
: review+
attinasi
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Page which exhibits the shifting behavior!
24.27 KB, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

On many pages, vertical regions of the page will be shifted by one pixel to the
left or right in relation to the rest of the page. This pertains to images as
well as text.

Reproducible: Sometimes
Steps to Reproduce:
1. Open the URL in a new window wide enough but not tall enough to hold the
whole image
2. Scroll to the end of the page
3. Scroll up again

Actual Results:  The part of the image that is redrawn is shifted one pixel to
the right

Expected Results:  Consistent rendering

This is a problem I have had since first using mozilla (0.95) and which has
appeared thru all versions so far, under Windows 98 as well as Windows XP. Since
it happens with many pages, I am surprised I couldn't find this bug listed yet.

The only non-standard setting I have I believe could be of relevance is that I
use large font sizes (120 dpi) in the advanced settings of the display properties.
WFM using 2002011503 Win2k.
Confirming issue in the Jan 22 build (2002-01-22-03) under Windows ME and OS X
(2002-01-18-08).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Changing to compositor.
Assignee: attinasi → kmcclusk
Component: Layout → Compositor
I resized the window so that only the horizontal scroll bar are active.
Dragging scroll bar up and down causes painting issue on image.
Target Milestone: --- → mozilla1.1
confirming issue with MacOS 9.1 build 2002-01-16-14
I'm seeing this problem on *lots* of sites
The same behaviour has been reported in bug 80530 which is almost definitely a 
dup. Thus this bug could be related to bug 63336, bug 87738 or bug 97861.
MacOS 9.1 2002012308
issue no longer present -- seems to have been solved implicitly ???
I'm still seeing this on 20020125 Linux.
Bulk moving Mozilla1.1 bugs to future-P2. I will pull from this list when
scheduling post Mozilla1.0 work.
Priority: -- → P2
Target Milestone: mozilla1.1 → Future
Blocks: 134942
adding christine to this. we were getting reports of this through another
channel indicating that link clicking (I've witnessed it on yahoo.com and
news.com) and text selection can cause text pixel shifting, it's very wierd and
can be subtle.

seeing this on a 04/01/02 trunk build on win2k.
Keywords: mozilla1.0, topembed+
OS: Windows XP → All
Attached patch Possible fix — — Splinter Review 
I can not reproduce the bug on WinXP with a current build. I have tried using
120DPI; 96DPIsettings and changing my screen resolution.

I instrumented the view manager code that is reponsible for blitting the
damaged area during painting and I noticed that the call to ScaleRoundOut on
the damaged rect was returning values that were not as close to the nearest
pixel as they should be after converting to twips. The patch corrects this.

Help wanted: I need someone who is seeing the off by one pixel problems and has
a current cvs build to apply my patch and see if it helps at all.
Target Milestone: Future → mozilla1.0
Jud: Can you apply my patch? 
I've been seeing this at 96 DPI. I will try the patch as soon as I get into the 
office this morning.
I could only reproduce the pixel shift after changing my system dpi to 120.
Links under on the Yahoo page are slightly after scrolling (and selection is
present) . The problem for me is that it appeared only once so I need to find
somes consistant steps to reproduce.  Tested under Windows ME with the April
09th trunk build (2002-04-09-03).
Ken are you using Win2K, WinXP, Win98, WinME?
What is your display resolution 800 X 600, 1024 X 768, etc?
What is your display depth: 256 colors, 32768 color, true color etc?
Under the windows display properties are you using small fonts or large fonts?
Are you seeing the problem in MfcEmbed, Mozilla, Netscape trunk builds?
If you are using Mozilla what setting do you have in the preferences under
appearance-fonts-display resolution. Is it 96DPI, 76DPI or some other custom
setting.
ok, let's see...I am using Win2k with a resolution of 1280x1024. display depth 
is true color (32bit). Font size is "small fonts, 96DPI". I see this in 0.9.9 
and trunk (my latest pull is a couple days old now) in mfcembed and mozilla. 
mozilla font resolution is set at the default 96 DPI.
I can see the problem consistently on this page when loading as a local file!!
Also by loading this bug in mozilla and clicking through to the attachment!

Click and hold on a link *or* select blocks of text and see it shift right 1
pixel....I have not changed from the settings listed above.
PATCH WORKS! Cool, verified and all that.
Sorry about the short post from yesterday. To clarify, I could reproduce the 
problem on my machine (specs in comment #16) 100% with the attached html 
content.

I patched my copy of gkview and could no longer reproduce the problem after 
many attempts.

Can we get this pushed to the trunk and 1.0 branch?
Note: I am seeking reviews/approval for attachment(id=78467). This patch fixes
the problem Ken is seeing at 96DPI but does not fix the general problem seen at
the 120DPI display setting. 

I can reproduce the problem on 120DPI, and the problem appears to be caused by a
combination of pixel roundoff errors in the twips to pixel conversion produced
as the result of inline frames not being positioned on pixel boundaries and
specific layout combinations (centered table rows). On www.yahoo.com the line
with: Personal: Addr Book · Briefcase · Calendar. etc is positioned at a
location that corresponds to 11.5 pixel when running in 120DPI mode. This is the
only line on that page which exhibits the off-by-one-pixel scrolling problem at
120DPI.
Keywords: review
Keywords: nsbeta1+
Whiteboard: [adt3]
Comment on attachment 78467 [details] [diff] [review]
Possible fix

sr=attinasi
Attachment #78467 - Flags: superreview+
I tested with www.yahoo.com / win2000, 96dpi / mozilla set to 96 dpi 

Result without Kevin's patch:

- Moving the edge of another app window over the links at the top causes the
strange one pixel shifting

Result with Kevin's patch:

- The bad beahviour (shifting) is repaired
Comment on attachment 78467 [details] [diff] [review]
Possible fix

r=dcone
Attachment #78467 - Flags: review+
This bug covers only the 96DPI case. bug 80530 covers the 120DPI case. The
underlying problems are different.
Summary: 1 pixel shift when rendering / scrolling → 1 pixel shift when rendering / scrolling (96DPI)
I just ran a few tests...confirmed that the 120DPI problem remains (display is 
set at 120DPI with mozilla at 96DPI).

I also found that the attached sample does not exhibit the problem in 
120DPI ... but I could see it at news.com
Comment on attachment 78467 [details] [diff] [review]
Possible fix

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #78467 - Flags: approval+
Keywords: adt1.0.0
adt1.0.0+ per adt
Keywords: adt1.0.0 → adt1.0.0+
Checked attachment 78467 [details] [diff] [review] into the Moz1.0.0 branch
Checked attachment 78467 [details] [diff] [review] into the trunk
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Is bug 112673 a dupe of this?
If the problem in bug 112673 happens when the display is set to 96DPI it should
be a dup of this. If the problem in bug 112673 happens when display is set to
120DPI then it is a dup of bug 80530. Reading through 112673 I didn't see any
mention of a DPI setting so I would assume that bug is a dup of this one.
Based on Ken's comments regarding 96dpi issue, marking verified.
Status: RESOLVED → VERIFIED
Keywords: verified1.0.0
Keywords: fixed1.0.0
This is still NOT FIXED for me. I synced to cvs 1.0branch 15 minutes ago
(20020413) and this does happen for me again on http://www.webfast.cz/, see:

http://Xtrmntr.org/ORBman/tmp/webfast.cz-96dpi.png

and I noticed this for the first time also in URLbar:

http://Xtrmntr.org/ORBman/tmp/webfast.cz-urlbar.png
http://Xtrmntr.org/ORBman/tmp/webfast.cz-urlbar2.png

this is what I get if I move windows over URLbar.

This does happen with Prefs/Appearance/Fonts/Display resolution: "System
settings". This (both content scrolling/loading and URLbar shifting) doesn't
happen when I change it to "96 dpi".

My system is Athlon CPU, Matrox G450, Hyundai F910 19", 1280x1024/16bpp,
xdpyinfo reports DPI 90x96, Mandrake 8.2 Linux, XFree84-4.2.0.

-> Reopen?
>> This (both content scrolling/loading and URLbar shifting) doesn't
>> happen when I change it to "96 dpi".

Martin,
For clarification, do you see any problems at 96DPI system setting? Are you 
changing the system font to 96DPI or mozilla?
When mozilla prefs set to 96DPI, I see no problems (for 1-2 weeks). When changed
to "system settings" -> problem. X server reports 90x96 and I also have
"default-resolutions = 90,96,100,100,75,75" line in /etc/X11/fs/config.

I also tried "default-resolutions = 96,96,100,100,75,75" with mozilla set to
"system settings" and the problem is still there.

The only thing that makes this problem go away is to set mozilla prefs to "96 dpi".
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: