Closed
Bug 426933
Opened 16 years ago
Closed 16 years ago
Border not drawn with very large padding and negative margin
Categories
(Core :: Graphics, defect, P2)
Core
Graphics
Tracking
()
RESOLVED
FIXED
People
(Reporter: polidobj, Assigned: vlad)
References
Details
(Keywords: regression, testcase)
Attachments
(2 files)
The borders in this testcase do not draw. 0318 ok 0319 broken http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-18+04%3A00%3A00&maxdate=2008-03-19+06%3A00%3A00&cvsroot=%2Fcvsroot If the padding and margin are lowered to around 16,000 then the borders are drawn. Sometimes if I put another window over where the borders should be and then move the window away part of the border is drawn. So I guess it's a gfx bug.
Flags: blocking1.9?
Comment 1•16 years ago
|
||
Maybe a regression from bug 422661 ? +'ing. Vlad, thoughts?
Assignee: nobody → vladimir
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Assignee | ||
Comment 2•16 years ago
|
||
The problem here is that while cairo itself no longer has a 16-bit coordinate limitation, pixman still does; if we ever need to render anything in software, or transform regions, we'll hit it. At this point I think we should fix this in 1.9.0.x with a cairo/pixman update; there's already work ongoing to do 24.8 fixed point inside pixman, but it won't be done in time for 1.9.0.0. Though we can back out the fix for 422661, and get a different set of brokenness.. not sure what the right thing is to do here. Cc'ing roc -- maybe we should use the correct coordinates on mac only, where pixman isn't involved, and keep it at 16-bit on linux and win32 for now?
Comment 3•16 years ago
|
||
Moving to 1.9.0.x per vlad's recommendation. Roc, if you disagree, please revert.
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: blocking1.9+
I agree, good decision.
Comment 6•16 years ago
|
||
Here's the reduced testcase from bug 434539.
Comment 7•16 years ago
|
||
FWIW, on the original testcase (attachment 313517 [details]), I see the outermost border on the main div (wrapping all of the content), but no borders between colored blocks.
I'm running:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0
Comment 8•16 years ago
|
||
(In reply to comment #0) > Sometimes if I put another window over where the borders should be and then > move the window away part of the border is drawn. I see this as well, on both testcases.
Updated•16 years ago
|
OS: Windows XP → All
Hardware: PC → All
Reporter | ||
Comment 9•16 years ago
|
||
As stated in Bug 434539 this problem affects the One True Layout hack for faking 100% height. So this could show up on a number of web sites if they use borders. http://www.positioniseverything.net/articles/onetruelayout/equalheight
Reporter | ||
Comment 10•16 years ago
|
||
I noticed this bug is fixed. I went back and found this was fixed starting with the 07-23 nightly. So I assume this was fixed by bug 446323. Are cairo updates allowed for 1.9.0.x? If not I guess the wanted1.9.0.x+ can be removed.
Comment 11•16 years ago
|
||
This isn't actually wanted for a maintenance release.
Flags: wanted1.9.0.x+
You need to log in
before you can comment on or make changes to this bug.
Description
•