Closed Bug 14385 Opened 25 years ago Closed 25 years ago

Think black vertical line

Categories

(Core :: Layout: Tables, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: gelderen, Assigned: dcone)

References

()

Details

(Whiteboard: [testcase])

Attachments

(1 file)

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.
Summary: Off by on error?
Summary: Off by on error? → Think black vertical line
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
Assignee: troy → karnaze
Component: Layout → HTMLTables
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'.
Attached file reduced test case
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
Looks like a duplicate of bug 5251.
Whiteboard: [testcase]
updating whiteboard
Assignee: karnaze → beard
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.
Status: NEW → ASSIGNED
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.
Target Milestone: M13
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.
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?
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.
Assignee: beard → dcone
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Fixed in the Jan 18th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: