RESOLVED FIXED 68641
Text drawn via -webkit-background-clip:text should be non-blurry with all scaling techniques
https://bugs.webkit.org/show_bug.cgi?id=68641
Summary Text drawn via -webkit-background-clip:text should be non-blurry with all sca...
Beth Dakin
Reported 2011-09-22 11:02:37 PDT
This is a followup bug from https://bugs.webkit.org/show_bug.cgi?id=67415 . RenderBoxModelObject has a static function named createDeviceScaledImageBuffer(). That function should take page scale, page zoom, and transforms from ancestors into account as well.
Attachments
Patch (4.56 KB, patch)
2011-09-22 17:29 PDT, Darin Adler
simon.fraser: review+
Darin Adler
Comment 1 2011-09-22 17:29:02 PDT
Simon Fraser (smfr)
Comment 2 2011-09-22 17:32:47 PDT
Comment on attachment 108428 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=108428&action=review r=me, perhaps with a little more thought about the naming. > Source/WebCore/platform/graphics/GraphicsContext.h:418 > + PassOwnPtr<ImageBuffer> createCompatibleBuffer(const IntSize&) const; I'm not sure that "compatible" says enough about the intent. It needs to communicate "appropriately scaled", or use a term like "resolution" or "scale". Maybe createScaledBuffer()?
Beth Dakin
Comment 3 2011-09-22 17:33:49 PDT
Looks good! It would be nice to add a test for this at some point. DumpRenderTree and WebKitTestRunner both have a scalePageBy function that tests the Page::setPageScaleFactor().
Darin Adler
Comment 4 2011-09-22 17:45:55 PDT
Comment on attachment 108428 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=108428&action=review >> Source/WebCore/platform/graphics/GraphicsContext.h:418 >> + PassOwnPtr<ImageBuffer> createCompatibleBuffer(const IntSize&) const; > > I'm not sure that "compatible" says enough about the intent. It needs to communicate "appropriately scaled", or use a term like "resolution" or "scale". Maybe createScaledBuffer()? Maybe createCompatiblyScaledBuffer? Part of why I named it this way is that eventually it might need to do something more than just scale--maybe set up an appropriate color space or something--but that’s a vague thought at the moment.
Darin Adler
Comment 5 2011-09-22 17:46:56 PDT
Before landing I probably should add a test. I also wonder whether it’s a bad policy for this to make a smaller buffer when things are scaled down. I think I should check for overflow. I wonder whether I need to add any rules about maximum buffer sizes. Probably already handled at the ImageBuffer level.
Beth Dakin
Comment 6 2011-10-13 17:15:46 PDT
(In reply to comment #5) > Before landing I probably should add a test. > > I also wonder whether it’s a bad policy for this to make a smaller buffer when things are scaled down. > > I think I should check for overflow. > > I wonder whether I need to add any rules about maximum buffer sizes. Probably already handled at the ImageBuffer level. I made a test for this, and I would like to check it in along with your patch. I'm just wondering if you have any further thoughts regarding the other possible changes you mentioned. I will think them over myself too.
Beth Dakin
Comment 7 2011-10-13 17:26:43 PDT
It seems like ImageBuffer takes care of overflow…of course we would end up with something of a strange size if we overflowed so much that we had a different positive number when performing the size * scale calculations in GraphicsContext. But ImageBuffer will at least protect us from crashing and and negative sizes.
Beth Dakin
Comment 8 2011-10-13 17:28:35 PDT
I also haven't been able to see any problems with creating a smaller image buffer when things are scaled down.
Beth Dakin
Comment 9 2011-10-14 11:14:13 PDT
Committed change with revision 97481.
Beth Dakin
Comment 10 2011-10-14 11:45:51 PDT
And a Leopard build fix with revision 97487.
Note You need to log in before you can comment on or make changes to this bug.