Bug 122565 - CoordinatedGraphics: Fix integer rounding when computing pixel alignment
Summary: CoordinatedGraphics: Fix integer rounding when computing pixel alignment
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Sergio Correia (qrwteyrutiyoup)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-09 12:09 PDT by Sergio Correia (qrwteyrutiyoup)
Modified: 2013-10-09 13:24 PDT (History)
6 users (show)

See Also:


Attachments
Patch (14.98 KB, patch)
2013-10-09 12:11 PDT, Sergio Correia (qrwteyrutiyoup)
no flags Details | Formatted Diff | Diff
v2--comment=More succint ChangeLog. (14.10 KB, patch)
2013-10-09 12:46 PDT, Sergio Correia (qrwteyrutiyoup)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sergio Correia (qrwteyrutiyoup) 2013-10-09 12:09:24 PDT
CoordinatedGraphics: Fix integer rounding when computing pixel alignment
Comment 1 Sergio Correia (qrwteyrutiyoup) 2013-10-09 12:11:44 PDT
Created attachment 213797 [details]
Patch

Proposed patch
Comment 2 Noam Rosenthal 2013-10-09 12:27:16 PDT
Comment on attachment 213797 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=213797&action=review

> Source/WebCore/ChangeLog:24
> +        In some situations, such as dealing with a mobile browser, which tries to
> +        calculate a scale factor to fit the contents to the viewport, we may get a
> +        small value for either width or height after scaling, which will cause the
> +        resulting FloatRect after being rounded to have this value be zero.
> +
> +        After converting back to the layer coordinates, we will still have this one
> +        value be zero, and that will cause problems in createTilesIfNeeded(), since
> +        in a previous step it will remove the layer's backing store, due to failing
> +        the check in layerShouldHaveBackingStore(), as the layer will be considered
> +        empty. At this point, we hit ASSERT(backingStore) in createTilesIfNeeded().
> +
> +        In this patch we replace the roundedIntRect() call with enclosingIntRect()
> +        in CoordinatedGraphicsLayer::computePixelAlignment().

Too much information here! All you're doing is changing to enclosingIntRect so that very small rectangles (after content scaling) don't appear to be empty, thus creating a crash later.
Comment 3 Sergio Correia (qrwteyrutiyoup) 2013-10-09 12:28:21 PDT
(In reply to comment #2)
> (From update of attachment 213797 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=213797&action=review
> 
> > Source/WebCore/ChangeLog:24
> > +        In some situations, such as dealing with a mobile browser, which tries to
> > +        calculate a scale factor to fit the contents to the viewport, we may get a
> > +        small value for either width or height after scaling, which will cause the
> > +        resulting FloatRect after being rounded to have this value be zero.
> > +
> > +        After converting back to the layer coordinates, we will still have this one
> > +        value be zero, and that will cause problems in createTilesIfNeeded(), since
> > +        in a previous step it will remove the layer's backing store, due to failing
> > +        the check in layerShouldHaveBackingStore(), as the layer will be considered
> > +        empty. At this point, we hit ASSERT(backingStore) in createTilesIfNeeded().
> > +
> > +        In this patch we replace the roundedIntRect() call with enclosingIntRect()
> > +        in CoordinatedGraphicsLayer::computePixelAlignment().
> 
> Too much information here! All you're doing is changing to enclosingIntRect so that very small rectangles (after content scaling) don't appear to be empty, thus creating a crash later.

Oops sorry. I was trying to explain the problem I observed, but I will use your words and make it way shorter.
Comment 4 Noam Rosenthal 2013-10-09 12:29:20 PDT
(In reply to comment #3)
> (In reply to comment #2)
> > (From update of attachment 213797 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=213797&action=review
> > 
> > > Source/WebCore/ChangeLog:24
> > > +        In some situations, such as dealing with a mobile browser, which tries to
> > > +        calculate a scale factor to fit the contents to the viewport, we may get a
> > > +        small value for either width or height after scaling, which will cause the
> > > +        resulting FloatRect after being rounded to have this value be zero.
> > > +
> > > +        After converting back to the layer coordinates, we will still have this one
> > > +        value be zero, and that will cause problems in createTilesIfNeeded(), since
> > > +        in a previous step it will remove the layer's backing store, due to failing
> > > +        the check in layerShouldHaveBackingStore(), as the layer will be considered
> > > +        empty. At this point, we hit ASSERT(backingStore) in createTilesIfNeeded().
> > > +
> > > +        In this patch we replace the roundedIntRect() call with enclosingIntRect()
> > > +        in CoordinatedGraphicsLayer::computePixelAlignment().
> > 
> > Too much information here! All you're doing is changing to enclosingIntRect so that very small rectangles (after content scaling) don't appear to be empty, thus creating a crash later.
> 
> Oops sorry. I was trying to explain the problem I observed, but I will use your words and make it way shorter.

It's ok! Better have too much information than too little :)
Comment 5 Sergio Correia (qrwteyrutiyoup) 2013-10-09 12:46:37 PDT
Created attachment 213800 [details]
v2--comment=More succint ChangeLog.
Comment 6 WebKit Commit Bot 2013-10-09 13:24:31 PDT
Comment on attachment 213800 [details]
v2--comment=More succint ChangeLog.

Clearing flags on attachment: 213800

Committed r157180: <http://trac.webkit.org/changeset/157180>
Comment 7 WebKit Commit Bot 2013-10-09 13:24:33 PDT
All reviewed patches have been landed.  Closing bug.