|Summary:||Drawing border-radius from path sometimes fails to round outer border in the double style when it should|
|Product:||WebKit||Reporter:||Beth Dakin <bdakin>|
|Component:||CSS||Assignee:||Simon Fraser (smfr) <simon.fraser>|
|Severity:||Normal||CC:||bdakin, simon.fraser, vikingjs|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.5|
|Bug Depends on:||58761|
Description Beth Dakin 2010-06-28 14:01:49 PDT
http://trac.webkit.org/changeset/62035 introduced a new method of drawing border-radius using paths. Right now, this new code is only enabled for some platforms…if you want to know if your favorite platform has the new code path enabled, see if it has been added to #define HAVE_PATH_BASED_BORDER_RADIUS_DRAWING in RenderObject.h. Attached is a test case that demonstrates a bug in the new code. The outer border should be rounded on the inside. This should probably be fixed in RenderBoxModelObject's borderWillArcInnerEdge. I included the following FIXME--> // FIXME: This test is insufficient. We need to take border style into account.
Comment 2 Jerry Seeger 2010-11-24 19:01:53 PST
Comment 3 Simon Fraser (smfr) 2010-11-26 10:42:30 PST
Patches are very welcome! Your success at getting it accepted will depend on: 1. Having performance data showing that it's no slower in common cases 2. If possible, splitting the patch up into bite-sized chunks that are easier to review. 3. Having good testcases.
Comment 4 Jerry Seeger 2010-11-27 14:26:16 PST
Super. I'll take a crack at it, then. I'm assuming there is documentation somewhere about gathering performance data. I should be able to gather a large number of cases where the current implementation falls short. Should I add them all here or open a new bug with them all collected? Splitting the patch up might be tricky, since it's a ground-up rebuild, but I'll keep that in mind as I port the code. (In reply to comment #3) > Patches are very welcome! Your success at getting it accepted will depend on: > 1. Having performance data showing that it's no slower in common cases > 2. If possible, splitting the patch up into bite-sized chunks that are easier to review. > 3. Having good testcases.
Comment 5 Simon Fraser (smfr) 2010-11-28 09:31:38 PST
(In reply to comment #4) > Super. I'll take a crack at it, then. I'm assuming there is documentation somewhere about gathering performance data. Not really, unfortunately, but once there's a patch here we can run it through some tests. > I should be able to gather a large number of cases where the current implementation falls short. Should I add them all here or open a new bug with them all collected? That depends on whether they are distinct issues that will be fixed by different parts of the patch. One way to keep the patch size down may be to first land some changes that are behaviorally compatible with the current code, then make bugs and patches to fix the remaining issues, if that's possible. Otherwise, one test case per unique issue is good once all is done. > Splitting the patch up might be tricky, since it's a ground-up rebuild, but I'll keep that in mind as I port the code. Understood.