The frame's x,y location should be adjusted to fall on a pixel boundary

RESOLVED INVALID

Status

()

P1
normal
RESOLVED INVALID
18 years ago
5 years ago

People

(Reporter: kmcclusk, Assigned: attinasi)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
In the process of converting from twips to pixel's we are sometimes off by one
pixel because of roundoff error. This results in calls to invalidate the frame's
rect which are sometimes 1 pixel too narrow. It may make sense to condition the
location of a frame so it's twip coordinates coorespond to pixel boundary.
The problem is the x,y coorindate may contain a twip value that is a fraction of
a pixel. When the width of the frame is added to the x coordinate the number of
pixels will vary depending on the x corrdinate's sub-pixel twip coordinate.

Comment 1

18 years ago
*** Bug 71524 has been marked as a duplicate of this bug. ***

Comment 2

18 years ago
This bug was split off of bug 63951 so that a hacky fix could be applied to 
that bug.
(Reporter)

Updated

17 years ago
Target Milestone: --- → mozilla0.9.8
(Reporter)

Updated

17 years ago
Target Milestone: mozilla0.9.8 → mozilla1.0.1
(Assignee)

Comment 3

17 years ago
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
dup of the general bug on units?
Whiteboard: DUPEME
No, but I disagree with the proposed solution. The real solution is for
Invalidate to round out the app-units-rect when converting to pixels.
therefore, marking INVALID
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID

Updated

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