Bug 11973 - WebKit does not respect boundingbox percentages larger than 1 (aka 100%)
Summary: WebKit does not respect boundingbox percentages larger than 1 (aka 100%)
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2006-12-25 20:21 PST by Eric Seidel (no email)
Modified: 2006-12-26 18:02 PST (History)
1 user (show)

See Also:

test case (333 bytes, image/svg+xml)
2006-12-25 20:21 PST, Eric Seidel (no email)
no flags Details
partial fix (9.66 KB, patch)
2006-12-25 22:34 PST, Eric Seidel (no email)
no flags Details | Formatted Diff | Diff
better partial fix (9.65 KB, patch)
2006-12-25 22:59 PST, Eric Seidel (no email)
no flags Details | Formatted Diff | Diff
fix (with test case changes) (162.60 KB, patch)
2006-12-26 08:08 PST, Eric Seidel (no email)
rwlbuis: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2006-12-25 20:21:17 PST
WebKit does not correctly respect 'r' attribute on radialGradient

It seems as though it's just treated at the wrong scale (pixels instead of percent of bbox)
Comment 1 Eric Seidel (no email) 2006-12-25 20:21:51 PST
Created attachment 12023 [details]
test case
Comment 2 Eric Seidel (no email) 2006-12-25 20:55:08 PST
it looks like the use of isFraction() is completely bogus.  That's the problem.
Comment 3 Eric Seidel (no email) 2006-12-25 22:34:58 PST
Created attachment 12024 [details]
partial fix

Attached is a partial fix.  It's only partial because it breaks most patterns (and strangely enough, some gradients?).  Our pattern code is actually now "more correct", but as a result allocates needlessly large image buffers for drawing the tile into.  We need to add some code to make tile drawing smarter, to scale the tile down to only the size necessary before allocating the ImageBuffer.  As a quick hack, we could simply divide by 100 (the previous behavior) or scale it down to just the size of the element-using-the-pattern's bounding box.  The best solution is to add a method which calculates the actual size of the pattern tile as it is to be rendered to the screen, and then allocate the ImageBuffer for that resolution.  This same sort of "finalRenderedSize()" function would be useful for the filter code as well (which already exhibits this same scaling problem).
Comment 4 Eric Seidel (no email) 2006-12-25 22:59:17 PST
Created attachment 12025 [details]
better partial fix

There are still a few test cases which are broken.  Also, w/o the added "only make the tile as large as it's going to be rendered" optimization certain tests are slowed down by this change (by allocating way-larger-than-necessary tile ImageBuffers).
Comment 5 Eric Seidel (no email) 2006-12-25 23:19:28 PST
Comment on attachment 12025 [details]
better partial fix

It turns out everything is actually OK with this patch.

Here's the fallout from these changes:


Have changed results.  The tests were depending on a bug in WebKit which is now fixed. :)  (At least I believe that to be the case.  When comparing with Opera, our results now match.)


This is a new test case which now actually works on TOT.


This test case now intermittently fails, depending on how much free memory the machine has (I think that's the reason).  This will be fixed for real once we are smarter about allocating pattern tile image buffers at their physical rendered size, instead of at some super-large logical size.
Comment 6 Eric Seidel (no email) 2006-12-26 08:08:15 PST
Created attachment 12029 [details]
fix (with test case changes)

custom/js-late-gradient-creation still looks a bit screwy until bug 11979 is fixed (bug 11979 was previously masked by this bug)

custom/pattern-in-defs may also intermittently fail still until bug 11980 is resolved.