Bug 76489 - REGRESSION: WebGL doesn't show up in CSS reflections
Summary: REGRESSION: WebGL doesn't show up in CSS reflections
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGL (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Antoine Quint
URL:
Keywords: InRadar, NRWT
Depends on:
Blocks:
 
Reported: 2012-01-17 15:51 PST by Simon Fraser (smfr)
Modified: 2016-06-03 00:50 PDT (History)
11 users (show)

See Also:


Attachments
Testcase (699 bytes, text/html)
2016-05-30 06:13 PDT, Antoine Quint
no flags Details
Patch (28.73 KB, patch)
2016-06-02 13:33 PDT, Antoine Quint
no flags Details | Formatted Diff | Diff
Patch for landing (28.85 KB, patch)
2016-06-03 00:19 PDT, Antoine Quint
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2012-01-17 15:51:49 PST
The pixel result of compositing/webgl/webgl-reflection.html shows that WebGL doesn't show in CSS reflections.
Comment 1 Filip Pizlo 2012-05-02 18:36:53 PDT
This appears to pass as of r115915
Comment 2 Simon Fraser (smfr) 2012-05-02 18:41:07 PDT
Actually it still fails. The output of NRWT is confusing when pixel testing is not active.
Comment 3 Simon Fraser (smfr) 2012-05-16 13:41:04 PDT
Specifically "Tests expected to fail but passed:" incorrectly lists tests that have expected IMAGE failure, even when pixel testing is not active.
Comment 4 Antoine Quint 2016-05-30 06:11:48 PDT
This isn't just a problem with DRT, this does not work in Safari with a simple test.
Comment 5 Radar WebKit Bug Importer 2016-05-30 06:12:09 PDT
<rdar://problem/26541236>
Comment 6 Antoine Quint 2016-05-30 06:13:00 PDT
Created attachment 280089 [details]
Testcase

The attached test case shows that the background color (blue) of the WebGL <canvas> is reflected but the actual WebGL content (fuchsia).
Comment 7 Antoine Quint 2016-05-31 09:33:13 PDT
I wonder if we should be doing extra work in PlatformCALayerCocoa::clone() so that the contentsLayer of the new newLayer is set. My guess is that the replication layer doesn't have a call to setContentsToPlatformLayer() like the replicated layer does.
Comment 8 Dean Jackson 2016-05-31 18:51:06 PDT
(In reply to comment #7)
> I wonder if we should be doing extra work in PlatformCALayerCocoa::clone()
> so that the contentsLayer of the new newLayer is set. My guess is that the
> replication layer doesn't have a call to setContentsToPlatformLayer() like
> the replicated layer does.

Without looking at the code, I would guess this should work the same as video. I think you're right that it does that via setContentsToPlatformLayer.
Comment 9 Antoine Quint 2016-06-01 05:16:58 PDT
In PlatformCALayerRemoteCustom::clone, I also see this which looks suspicious in order to get reflections working on iOS:

    if (layerType() == LayerTypeWebGLLayer) {
        clonedLayer = adoptNS([[CALayer alloc] init]);
        // FIXME: currently copying WebGL contents breaks the original layer.
        copyContents = false;
    }
Comment 10 Antoine Quint 2016-06-02 08:48:18 PDT
My current understanding of this issue is that reflections are updated to match their replicated layer's content in GraphicsLayerCA::layerDidDisplay where we iterate through the layer clones. There, we check whether the layer that displayed was the layer itself or its content layer. In the case of a <canvas> element using WebGL, we only get notifications for the layer, not the content layer. However, the content layer is the one which has its backing CALayer's contents set to the WebGLLayer's content, so without this notification the code doesn't update the content layer's clones.

I'm not sure why these notifications aren't fired.

As for <video> elements, their reflections work out due to specific work done in PlatformCALayerCocoa::clone to set the AVPlayer of the cloned layer (the replica) to the original layer (the replicated layer).

Not sure yet if we should add WebGL-specific code in PlatformCALayerCocoa::clone or get GraphicsLayerCA::layerDidDisplay to be called with the content layer of a GraphicsLayerCA backing a WebGL <canvas> element. My hunch is the latter, which should trigger once the WebGLLayer has been drawn.
Comment 11 Antoine Quint 2016-06-02 09:20:20 PDT
The problem was indeed the lack of GraphicsLayerCA::layerDidDisplay notification for the content layer. The issue was that the [CALayer display] override in WebGLLayer did not call dispatch the notification the way WebLayer does.
Comment 12 Antoine Quint 2016-06-02 09:25:56 PDT
This doesn't fix iOS though, which is probably due to PlatformCALayerRemoteCustom::clone.
Comment 13 Antoine Quint 2016-06-02 13:33:06 PDT
Created attachment 280357 [details]
Patch
Comment 14 Antoine Quint 2016-06-02 13:36:31 PDT
I raised https://bugs.webkit.org/show_bug.cgi?id=158314 for iOS support.
Comment 15 Dean Jackson 2016-06-02 13:37:03 PDT
Comment on attachment 280357 [details]
Patch

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

> Source/WebCore/ChangeLog:12
> +
> +        * platform/graphics/mac/WebGLLayer.mm:

Mention the existing test.
Comment 16 Antoine Quint 2016-06-03 00:19:48 PDT
Created attachment 280430 [details]
Patch for landing
Comment 17 WebKit Commit Bot 2016-06-03 00:50:52 PDT
Comment on attachment 280430 [details]
Patch for landing

Clearing flags on attachment: 280430

Committed r201639: <http://trac.webkit.org/changeset/201639>
Comment 18 WebKit Commit Bot 2016-06-03 00:50:57 PDT
All reviewed patches have been landed.  Closing bug.