WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
11973
WebKit does not respect boundingbox percentages larger than 1 (aka 100%)
https://bugs.webkit.org/show_bug.cgi?id=11973
Summary
WebKit does not respect boundingbox percentages larger than 1 (aka 100%)
Eric Seidel (no email)
Reported
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)
Attachments
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
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2006-12-25 20:21:51 PST
Created
attachment 12023
[details]
test case
Eric Seidel (no email)
Comment 2
2006-12-25 20:55:08 PST
it looks like the use of isFraction() is completely bogus. That's the problem.
Eric Seidel (no email)
Comment 3
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).
Eric Seidel (no email)
Comment 4
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).
Eric Seidel (no email)
Comment 5
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: custom/js-late-gradient-and-object-creation custom/js-late-gradient-creation 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.) custom/large-bounding-box-percents. This is a new test case which now actually works on TOT. custom/pattern-in-defs 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.
Eric Seidel (no email)
Comment 6
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug