The large image will request its first frame to be decoded once it is drawn. This should improve the first time paint scenario. It can also improve the scrolling scenario if the image is drawn on a tile outside the viewport.
Created attachment 295358[details]
Archive of layout-test-results from ews103 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295359[details]
Archive of layout-test-results from ews116 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews116 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295360[details]
Archive of layout-test-results from ews124 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews124 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Created attachment 295361[details]
Archive of layout-test-results from ews107 for mac-yosemite-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Created attachment 295385[details]
Archive of layout-test-results from ews102 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295388[details]
Archive of layout-test-results from ews102 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295389[details]
Archive of layout-test-results from ews104 for mac-yosemite-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Created attachment 295390[details]
Archive of layout-test-results from ews117 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295391[details]
Archive of layout-test-results from ews121 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews121 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Created attachment 295401[details]
Archive of layout-test-results from ews102 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295403[details]
Archive of layout-test-results from ews115 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295468[details]
Archive of layout-test-results from ews103 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295470[details]
Archive of layout-test-results from ews114 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295479[details]
Archive of layout-test-results from ews102 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 295480[details]
Archive of layout-test-results from ews117 for mac-yosemite
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 302355[details]
Archive of layout-test-results from ews124 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews124 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Created attachment 302449[details]
Archive of layout-test-results from ews115 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 302501[details]
Archive of layout-test-results from ews115 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 302494[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=302494&action=review
It's really unfortunate that we pass MaxPixelSize down through all these functions. Can we pass down something like a std::optional<IntSize>sizeForDraw or something instead?
> Source/WebCore/ChangeLog:20
> + If image source size is large (e.g. 3000x3000 pixels) and the size of the
> + destination rectangle is small, CGImageSourceCreateThumbnailAtIndex() is
> + slower than CGImageSourceCreateImageAtIndex() in decoding this image. To
> + overcome this problem, the entry (kCGImageSourceThumbnailMaxPixelSize,
> + max(destinationRect.width, destinationRect.height)) is added to the options
> + dictionary when calling CGImageSourceCreateThumbnailAtIndex(). This will
> + avoid copying a large block of memory for the unscaled bitmap image.
This seems like a different patch. I think you should split this into 2.
> Source/WebCore/loader/cache/CachedImage.h:129
> + URL sourceUrl() const override { return m_cachedImages[0]->url(); }
Is m_cachedImages guaranteed to have at least one entry?
> Source/WebCore/page/FrameView.h:278
> + void requestAsyncDecodingForImagesInRectIncludingSubframes(const IntRect&);
This needs to be more specific about what coordinate system 'rect' is in. Is it document coords, or view coords? Does it change with zooming?
> Source/WebCore/page/FrameView.h:653
> + void requestAsyncDecodingForImagesInRect(const IntRect&);
Ditto.
> Source/WebCore/platform/graphics/BitmapImage.cpp:246
> +bool BitmapImage::isAsyncDecodingRequired()
Can this be const?
> Source/WebCore/platform/graphics/BitmapImage.h:136
> + String sourceURL() const { return imageObserver() ? imageObserver()->sourceUrl().string() : ""; }
More efficient to use emptyString() than "".
> Source/WebCore/platform/graphics/BitmapImage.h:210
> + MaxPixelSize m_currentMaxPixelSize { MaxPixelSizeNative };
It's not clear what this means. What is the context of "current"? What does "max pixel size" mean for a BitmapImage?
> Source/WebCore/platform/graphics/ImageFrame.h:76
> +typedef int MaxPixelSize;
You plumb MaxPixelSize through a lot of functions, and it's hard to know what it means.
> Source/WebCore/platform/graphics/ImageFrame.h:79
> + MaxPixelSizeUndefined = -1,
We try to avoid magic -1 numbers. Can we use std::optional instead?
Created attachment 303569[details]
Archive of layout-test-results from ews106 for mac-elcapitan-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Created attachment 303572[details]
Archive of layout-test-results from ews114 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 303573[details]
Archive of layout-test-results from ews103 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 303576[details]
Archive of layout-test-results from ews122 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Created attachment 303690[details]
Patch for 165039 separate from 168814
This patch gets rid of using descendantsOfType<RenderImage>() in RenderView::requestAsyncDecodingForImagesInDocumentRect(). Instead it uses a HashSet of RenderElement which is built by the HTMLImageElement.
I am working on a test. But I have to implement the ondecode event instead of using a timer. If it turns out implementing the ondecode event is very involving, I will fallback to using the timer.
Comment on attachment 303690[details]
Patch for 165039 separate from 168814
View in context: https://bugs.webkit.org/attachment.cgi?id=303690&action=review> Source/WebCore/platform/graphics/BitmapImage.cpp:178
> + if (!frameHasDecodedNativeImage(m_currentFrame))
> + return;
Don't we want to paint the yellow debug color here too?
> Source/WebCore/platform/graphics/BitmapImage.cpp:409
> + imageObserver()->changedInRect(this, nullptr);
When is newFrameNativeImageAvailableAtIndex() called? If it's during painting, the repaint triggered by changedInRect() will get dropped on the floor.
> Source/WebCore/platform/graphics/BitmapImage.cpp:422
> + if (m_source.requestFrameAsyncDecodingAtIndex(0, m_currentSubsamplingLevel, sizeForDrawing))
> + LOG(Images, "BitmapImage::%s - %p - url: %s", __FUNCTION__, this, sourceURL().characters8());
I would prefer not doing work inside the if (), the LOGging here too.
> Source/WebCore/rendering/RenderElement.cpp:1440
> + LayoutRect backgroundPaintingRect = backgroundIsPaintedByRoot ? view().backgroundRect() : absoluteClippedOverflowRect();
absoluteClippedOverflowRect is expensive. We should keep an eye out for this being a perf bottleneck.
> Source/WebCore/rendering/RenderElement.cpp:1506
> +void RenderElement::unregisterForAsyncImageDecodingCallback()
It makes me nervous that we rely on HTMLImageElement() to call this to get unregistered from the RenderView. If there's any code path where that call doesn't happen, then we have a security bug. I would prefer any RenderElement that was registered is able to unregister itself on teardown.
> Source/WebCore/rendering/RenderElement.h:140
> + bool intersects(const IntRect&) const;
This should be called intersectsAbsoluteRect or something that clarifies the coordinate system of the rect.
> Source/WebCore/rendering/RenderView.cpp:1430
> + if (!m_largeImageRenderers.contains(&renderer))
> + m_largeImageRenderers.add(&renderer);
Don't call contains before add. That's two hash lookups instead of one.
> Source/WebCore/rendering/RenderView.cpp:1436
> + if (m_largeImageRenderers.contains(&renderer))
> + m_largeImageRenderers.remove(&renderer);
Don't call contains just to remove! that's two hash lookups instead of one.
> Source/WebCore/rendering/RenderView.h:394
> + HashSet<RenderElement*> m_largeImageRenderers;
The same "m_largeImageRenderers" should match the function names "registerForAsyncImageDecodingCallback", so this should be m_asyncDecodingImageRenderers.
> Source/WebCore/testing/Internals.cpp:478
> + if (InternalSettings* settings = this->settings())
> + settings->setLargeImageAsyncDecodingEnabled(false);
That's not the correct way to disable a setting for testing. You should do it via code in DRT/WTR which changes the WK1 or WK2 pref.
Comment on attachment 303690[details]
Patch for 165039 separate from 168814
View in context: https://bugs.webkit.org/attachment.cgi?id=303690&action=review>> Source/WebCore/platform/graphics/BitmapImage.cpp:178
>> + return;
>
> Don't we want to paint the yellow debug color here too?
Yes. Fixed.
>> Source/WebCore/platform/graphics/BitmapImage.cpp:409
>> + imageObserver()->changedInRect(this, nullptr);
>
> When is newFrameNativeImageAvailableAtIndex() called? If it's during painting, the repaint triggered by changedInRect() will get dropped on the floor.
newFrameNativeImageAvailableAtIndex() is called from the decoding thread via callOnMainThread(). So missing a repaint should not happen.
>> Source/WebCore/platform/graphics/BitmapImage.cpp:422
>> + LOG(Images, "BitmapImage::%s - %p - url: %s", __FUNCTION__, this, sourceURL().characters8());
>
> I would prefer not doing work inside the if (), the LOGging here too.
Done.
>> Source/WebCore/rendering/RenderElement.cpp:1506
>> +void RenderElement::unregisterForAsyncImageDecodingCallback()
>
> It makes me nervous that we rely on HTMLImageElement() to call this to get unregistered from the RenderView. If there's any code path where that call doesn't happen, then we have a security bug. I would prefer any RenderElement that was registered is able to unregister itself on teardown.
Done. I added a call to unregisterForAsyncImageDecodingCallback(*this) in the destructor of RenderElement.
>> Source/WebCore/rendering/RenderElement.h:140
>> + bool intersects(const IntRect&) const;
>
> This should be called intersectsAbsoluteRect or something that clarifies the coordinate system of the rect.
Done. Function is renamed.
>> Source/WebCore/rendering/RenderView.cpp:1430
>> + m_largeImageRenderers.add(&renderer);
>
> Don't call contains before add. That's two hash lookups instead of one.
Done. Instead I added isRegisteredForAsyncImageDecodingCallback() to RenderObject().
>> Source/WebCore/rendering/RenderView.cpp:1436
>> + m_largeImageRenderers.remove(&renderer);
>
> Don't call contains just to remove! that's two hash lookups instead of one.
Done.
>> Source/WebCore/rendering/RenderView.h:394
>> + HashSet<RenderElement*> m_largeImageRenderers;
>
> The same "m_largeImageRenderers" should match the function names "registerForAsyncImageDecodingCallback", so this should be m_asyncDecodingImageRenderers.
Done. Member was renamed.
>> Source/WebCore/testing/Internals.cpp:478
>> + settings->setLargeImageAsyncDecodingEnabled(false);
>
> That's not the correct way to disable a setting for testing. You should do it via code in DRT/WTR which changes the WK1 or WK2 pref.
Done. DRT and WTR was changed to disable the large image decoding.
Comment on attachment 303849[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=303849&action=review> Source/WebCore/page/FrameView.cpp:1063
> + requestAsyncDecodingForImagesInAbsoluteRectIncludingSubframes(tiledBacking->tileCoverageRect());
Please fix the comment in TiledBacking that says:
// Exposed for testing
virtual IntRect tileCoverageRect() const = 0;
> Source/WebCore/platform/graphics/BitmapImage.cpp:420
> + LOG(Images, "BitmapImage::%s - %p - url: %s [earlyFrameCount = %ld nextFrame = %ld]", __FUNCTION__, this, sourceURL().characters8(), ++m_earlyFrameCount, index);
Better to use string.utf8().data().
> Source/WebCore/platform/graphics/BitmapImage.cpp:444
> + LOG(Images, "BitmapImage::%s - %p - url: %s", __FUNCTION__, this, sourceURL().characters8());
Better to use string.utf8().data().
> Source/WebCore/rendering/RenderView.cpp:1451
> + float scale = frame().frameScaleFactor() * frame().pageZoomFactor() * document().deviceScaleFactor();
> + if (frame().settings().delegatesPageScaling())
> + scale *= frame().page()->pageScaleFactor();
frameScaleFactor() IS pageScaleFactor() if !delegatesPageScaling, so this is super confusing. I think you just want .page()->pageScaleFactor() * frame().pageZoomFactor() * document().deviceScaleFactor();
> Source/WebCore/rendering/RenderView.cpp:1452
> + image->image()->requestAsyncDecoding(expandedIntSize(renderer->objectBoundingBox().size() * scale));
objectBoundingBox isn't the right box, and may be slightly different from the rendered size, leading to slight resizing artifacts. You need to use the rect that RenderImage::paintReplaced() uses.
In addition, you need to file a bug to track taking ancestor transforms into account, including ancestor SVG transforms.
I really think we should just delay this request until paint time to avoid having to do all the math again. I don't think we'll get it right doing it here.
Comment on attachment 303849[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=303849&action=review>> Source/WebCore/platform/graphics/BitmapImage.cpp:420
>> + LOG(Images, "BitmapImage::%s - %p - url: %s [earlyFrameCount = %ld nextFrame = %ld]", __FUNCTION__, this, sourceURL().characters8(), ++m_earlyFrameCount, index);
>
> Better to use string.utf8().data().
Done.
>> Source/WebCore/platform/graphics/BitmapImage.cpp:444
>> + LOG(Images, "BitmapImage::%s - %p - url: %s", __FUNCTION__, this, sourceURL().characters8());
>
> Better to use string.utf8().data().
Done.
>> Source/WebCore/rendering/RenderView.cpp:1451
>> + scale *= frame().page()->pageScaleFactor();
>
> frameScaleFactor() IS pageScaleFactor() if !delegatesPageScaling, so this is super confusing. I think you just want .page()->pageScaleFactor() * frame().pageZoomFactor() * document().deviceScaleFactor();
Done.
>> Source/WebCore/rendering/RenderView.cpp:1452
>> + image->image()->requestAsyncDecoding(expandedIntSize(renderer->objectBoundingBox().size() * scale));
>
> objectBoundingBox isn't the right box, and may be slightly different from the rendered size, leading to slight resizing artifacts. You need to use the rect that RenderImage::paintReplaced() uses.
>
> In addition, you need to file a bug to track taking ancestor transforms into account, including ancestor SVG transforms.
>
> I really think we should just delay this request until paint time to avoid having to do all the math again. I don't think we'll get it right doing it here.
Filed https://bugs.webkit.org/show_bug.cgi?id=169396.
Created attachment 304139[details]
Archive of layout-test-results from ews105 for mac-elcapitan-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Created attachment 304140[details]
Archive of layout-test-results from ews102 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 304141[details]
Archive of layout-test-results from ews113 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews113 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 304164[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=304164&action=review
We need to test that the right thing happens for a directly composited image, but otherwise this looks OK.
> Source/WebCore/platform/graphics/BitmapImage.cpp:166
> + m_sizeForDrawing = enclosingIntRect(context.getCTM().mapRect(destRect)).size();
I trust this works for retina, page zoom etc?
> Source/WebCore/platform/graphics/BitmapImage.cpp:179
> + if (isLargeImageAsyncDecodingRequired()) {
Not new to this patch, but the "required" sounds too strong here. Would read better as "shouldUseAsyncDecoding" or something.
> Source/WebCore/platform/graphics/BitmapImage.cpp:435
> + if (m_needsRepaint) {
I'm not convinced of the necessity of having the m_needsRepaint member. When would newFrameNativeImageAvailableAtIndex() get called when you do *not* want to call changedInRect?
> Source/WebCore/platform/graphics/BitmapImage.cpp:440
> + // Keep the number of decoding threads under control.
This seems a bit vague. Maybe just remove the comment.
> Source/WebCore/platform/graphics/cg/ImageDecoderCG.cpp:384
> + // CGImageSourceCreateThumbnailAtIndex() creates a bitmap context with the image native size
> + // regardless of the subsamplingLevel unless kCGImageSourceSubsampleFactor is passed. Getting
> + // frameSizeAtIndex(index, subsamplingLevel) will return irrelevant size to the size of image
> + // that is going to be created so get frameSizeAtIndex() for SubsamplingLevel::Default and
> + // compare it with sizeForDrawing.
I'm having a hard time understanding this comment. First, CGImageSourceCreateThumbnailAtIndex() doesn't crate a bitmap context, it creates a CGImageRef, and it sounds like correct behavior for it to use the native image size unless you specify kCGImageSourceSubsampleFactor. Does passing SubsamplingLevel::Default here just ensure that *our* code behaves as we want?
Comment on attachment 304164[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=304164&action=review>> Source/WebCore/platform/graphics/BitmapImage.cpp:166
>> + m_sizeForDrawing = enclosingIntRect(context.getCTM().mapRect(destRect)).size();
>
> I trust this works for retina, page zoom etc?
Yes this works with page zoom and view zoom correctly.
>> Source/WebCore/platform/graphics/BitmapImage.cpp:179
>> + if (isLargeImageAsyncDecodingRequired()) {
>
> Not new to this patch, but the "required" sounds too strong here. Would read better as "shouldUseAsyncDecoding" or something.
Done. Functions were renamed.
>> Source/WebCore/platform/graphics/BitmapImage.cpp:435
>> + if (m_needsRepaint) {
>
> I'm not convinced of the necessity of having the m_needsRepaint member. When would newFrameNativeImageAvailableAtIndex() get called when you do *not* want to call changedInRect?
Done. You are right m_needsRepaint is not needed.
>> Source/WebCore/platform/graphics/BitmapImage.cpp:440
>> + // Keep the number of decoding threads under control.
>
> This seems a bit vague. Maybe just remove the comment.
The comment was removed.
>> Source/WebCore/platform/graphics/cg/ImageDecoderCG.cpp:384
>> + // compare it with sizeForDrawing.
>
> I'm having a hard time understanding this comment. First, CGImageSourceCreateThumbnailAtIndex() doesn't crate a bitmap context, it creates a CGImageRef, and it sounds like correct behavior for it to use the native image size unless you specify kCGImageSourceSubsampleFactor. Does passing SubsamplingLevel::Default here just ensure that *our* code behaves as we want?
I changed the comment a little. What I meant here is the following:
CGImageSourceCreateThumbnailAtIndex() calls CGBitmapContextCreate() to create a CGContext with the image native size regardless of the subsamplingLevel unless kCGImageSourceSubsampleFactor is passed. It then calls CGBitmapContextCreateImage() to get the frame CGImage. Here we are trying to see which size is smaller: the image native size or the sizeForDrawing(). Assuming that frameSizeAtIndex(index, subsamplingLevel) will return the size which CGBitmapContextCreate() will be called with was wrong. To fix this issue we need to get frameSizeAtIndex() for SubsamplingLevel::Default and compare it the sizeForDrawing.
(In reply to comment #98)
> Comment on attachment 304164[details]
> Patch
>
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=304164&action=review
>
> We need to test that the right thing happens for a directly composited
> image, but otherwise this looks OK.
>
Did you mean something like this?
<style>
.transformed {
transform: scale(2);
transform-origin: top left;
width: 400px;
height: 400px;
}
</style>
<body>
<div class="transformed">
<img src="image.jpg">
</div>
</body>
I tested this case and the quality of the image is correct.
(In reply to comment #101)
> (In reply to comment #98)
> > Comment on attachment 304164[details]
> > Patch
> >
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=304164&action=review
> >
> > We need to test that the right thing happens for a directly composited
> > image, but otherwise this looks OK.
> >
>
> Did you mean something like this?
>
> <style>
> .transformed {
> transform: scale(2);
> transform-origin: top left;
> width: 400px;
> height: 400px;
> }
> </style>
> <body>
> <div class="transformed">
> <img src="image.jpg">
> </div>
> </body>
No, more like this:
<img src="image.jpg" style="will-change: transform">
Comment on attachment 304176[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=304176&action=review> Source/WebCore/platform/graphics/cg/ImageDecoderCG.cpp:385
> + // CGImageSourceCreateThumbnailAtIndex() returns a CGImage with the image native size
> + // regardless of the subsamplingLevel unless kCGImageSourceSubsampleFactor is passed.
> + // Here we are trying to see which size is smaller: the image native size or the
> + // sizeForDrawing. If we want a CGImage with the image native size, sizeForDrawing will
> + // not passed. So we need to get the image native size with the default subsampling and
> + // then compare it with sizeForDrawing.
Much clearer, thanks!
(In reply to comment #102)
> (In reply to comment #101)
> > (In reply to comment #98)
> > > Comment on attachment 304164[details]
> > > Patch
> > >
> > > View in context:
> > > https://bugs.webkit.org/attachment.cgi?id=304164&action=review
> > >
> > > We need to test that the right thing happens for a directly composited
> > > image, but otherwise this looks OK.
> > >
> >
> > Did you mean something like this?
> >
> > <style>
> > .transformed {
> > transform: scale(2);
> > transform-origin: top left;
> > width: 400px;
> > height: 400px;
> > }
> > </style>
> > <body>
> > <div class="transformed">
> > <img src="image.jpg">
> > </div>
> > </body>
>
>
> No, more like this:
>
> <img src="image.jpg" style="will-change: transform">
This scenario runs correctly but through the synchronous decoding path. RenderLayerBacking::updateImageContents() calls GraphicsLayerCA::setContentsToImage() which calls BitmapImage::nativeImageForCurrentFrame(). This later function forces synchronous when it calls frameImageAtIndex with a null sizeForDrawing.
2016-11-22 23:12 PST, Said Abou-Hallawa
2016-11-22 23:30 PST, Said Abou-Hallawa
2016-11-22 23:48 PST, Said Abou-Hallawa
2016-11-22 23:53 PST, Said Abou-Hallawa
2016-11-23 00:42 PST, Build Bot
2016-11-23 00:52 PST, Build Bot
2016-11-23 01:15 PST, Build Bot
2016-11-23 01:47 PST, Build Bot
2016-11-23 15:10 PST, Said Abou-Hallawa
2016-11-23 15:35 PST, Said Abou-Hallawa
2016-11-23 16:43 PST, Build Bot
2016-11-23 16:48 PST, Said Abou-Hallawa
2016-11-23 17:47 PST, Build Bot
2016-11-23 17:59 PST, Build Bot
2016-11-23 18:03 PST, Build Bot
2016-11-23 18:11 PST, Build Bot
2016-11-24 01:59 PST, Said Abou-Hallawa
2016-11-24 03:06 PST, Build Bot
2016-11-24 03:19 PST, Build Bot
2016-11-27 11:22 PST, Said Abou-Hallawa
2016-11-27 13:59 PST, Said Abou-Hallawa
2016-11-27 14:08 PST, Said Abou-Hallawa
2016-11-27 14:48 PST, Build Bot
2016-11-27 15:06 PST, Build Bot
2016-11-27 19:59 PST, Said Abou-Hallawa
2016-11-27 21:00 PST, Build Bot
2016-11-27 21:07 PST, Build Bot
2016-11-27 21:47 PST, Said Abou-Hallawa
2016-11-28 01:06 PST, Said Abou-Hallawa
2016-11-28 10:52 PST, Said Abou-Hallawa
2017-02-21 18:19 PST, Said Abou-Hallawa
2017-02-21 19:32 PST, Build Bot
2017-02-22 13:48 PST, Said Abou-Hallawa
2017-02-22 15:18 PST, Build Bot
2017-02-22 22:27 PST, Said Abou-Hallawa
2017-02-23 01:19 PST, Build Bot
2017-03-06 14:17 PST, Said Abou-Hallawa
2017-03-06 15:26 PST, Build Bot
2017-03-06 15:33 PST, Build Bot
2017-03-06 15:38 PST, Build Bot
2017-03-06 15:59 PST, Build Bot
2017-03-06 18:24 PST, Said Abou-Hallawa
2017-03-06 18:27 PST, Said Abou-Hallawa
2017-03-07 11:32 PST, Said Abou-Hallawa
2017-03-07 11:39 PST, Said Abou-Hallawa
2017-03-07 20:46 PST, Said Abou-Hallawa
2017-03-08 08:43 PST, Said Abou-Hallawa
2017-03-08 15:01 PST, Said Abou-Hallawa
2017-03-08 17:09 PST, Said Abou-Hallawa
2017-03-10 21:53 PST, Said Abou-Hallawa
2017-03-10 22:58 PST, Build Bot
2017-03-10 23:01 PST, Build Bot
2017-03-10 23:09 PST, Build Bot
2017-03-11 00:59 PST, Said Abou-Hallawa
2017-03-11 09:59 PST, Said Abou-Hallawa
2017-03-11 14:12 PST, Said Abou-Hallawa