Closed
Bug 14385
Opened 25 years ago
Closed 25 years ago
Think black vertical line
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
VERIFIED
FIXED
M13
People
(Reporter: gelderen, Assigned: dcone)
References
()
Details
(Whiteboard: [testcase])
Attachments
(1 file)
535 bytes,
text/html
|
Details |
If you look at the page with 1999091914 on Win98 you will see four buttons at the top. If your browser is buggy too, you will see a thin black vertical line between the Action and the Mission button. In addition the right collumn of the page appears to be shifted right by one pixel.
One problem per bug report, please. It makes it easier to track and verify. This bug report is for the first issue you report, the thin black vertical line between the 'action' and 'mission' buttons
Chris, the issue seems to be that 593 is not evenly visible by 4 and so there's one pixel extra. Notice that as you resize the window the one pixel black line moves around. Sometimes it's between 'members' and 'resources'.
Chris, I created a very small reduced test case. Note that I think the other problem mentioned in the bug report (right column of the page appears to be shifted right by one pixel)is related
Updated•25 years ago
|
Assignee: karnaze → beard
Comment 7•25 years ago
|
||
Patrick, the table cell frames have no gaps in them to cause this (as indicated by dump frames in Viewer). I put printf statements in nsTableCellFrame::Paint listing the dirty rect and the rect of the nsTableCellFrame, but don't know enough about what it means to determine what the problem is.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 8•25 years ago
|
||
The cell frames are drawn with gaps on the Mac as well, I think because of round-off error within GFX. The orange cell backgrounds are drawn using nsIRenderingContext::FillRect(const nsRect&), passing rects with (x,y)=(0,0). Somehow, the right and left edges of the first and second cells aren't lining up in Quickdraw space. The right edge of the first cell ends up being 171, whereas the left edge of the second cell is 172, hence the black line.
Updated•25 years ago
|
Target Milestone: M13
Comment 9•25 years ago
|
||
I think the strategy of translating the rendering context using the (x,y) of the table cells in nsTableRowFrame::PaintChildren() may be the culprit here. Perhaps it's our use of floating point to keep track of the translation.
Comment 10•25 years ago
|
||
I took a look at the rounding code going on in nsTransform2D::TransformCoord() and it struck me that the way we're adding in the translation is just bound to cause more errors than are necessary. It turns out, that we're rounding twice. Here's the code in question: *ptX = NSToCoordRound(*ptX * m00) + NSToCoordRound(m20); Since rounding occurs twice, then it is possible to get the effect we're seeing. If I change the code to: *ptX = NSToCoordRound(*ptX * m00 + m20); then the problem goes away, because there is less round-of error. Opinions?
Assignee | ||
Comment 11•25 years ago
|
||
f you take the rounding out then UNIX and all the widgets, lines etc will draw inconsistently depending on which boundaries they are on. The fix I put in cleaned up alot of the line drawing. The problems were. One the same page a double border might draw fine and down further they would collide(looked like a fat line) Radio and rounded rects would differently depending on what part of the page they were placed. Unix was all messed up because the coordinate system had pixels centered between coordinates (not upper left like Mac) etc... The problem with our matrix is not linear.. and we continue to concat them rounded which builds in a terrible rounding problem. This was all done to get a centered pixel (according to Kipp) like Unix depends on. So what I discovered was you have to round the translation independently of the scale.. this makes the transformations pop onto integer boundaries. The amount you translate (as an integer amount) needs to be rounded independently of the scale rounding. The lines you are putting down probably are being calculated in twips.. and the placement of the twips require for the screen that they fall onto pixel boundaries. Or the spacing is a true pixel width. The fix you propose just happend to round in a way that made the symptom go away. I will look at the bug and see if I might find a quick way to pop that guy onto a pixel boundary.. I did some of that in nsCSSRendering for the rounded rectangles.
Updated•25 years ago
|
Assignee: beard → dcone
Status: ASSIGNED → NEW
Comment 12•25 years ago
|
||
So you're saying we have to condition our coordinates so that twips fall on pixel boundaries? Then why the heck are we using twips at all? Unless we can use twips generally, there's absolutely no reason to be using them. I'm reassigning this bug to Don, since he understands these issues so well.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 13•25 years ago
|
||
Fixed. There were problems with the translation matrix. I had to add an error to the width and height, this will pop everything onto the correct pixel boundaries.
You need to log in
before you can comment on or make changes to this bug.
Description
•