Title: [262498] trunk
- Revision
- 262498
- Author
- [email protected]
- Date
- 2020-06-03 11:48:00 -0700 (Wed, 03 Jun 2020)
Log Message
[ macOS ] REGRESSION(r262366): webgl/1.0.3/conformance/canvas/buffer-offscreen-test.html & webgl/2.0.0/conformance/canvas/buffer-offscreen-test.html are constant failures
https://bugs.webkit.org/show_bug.cgi?id=212594
<rdar://problem/63828783>
Reviewed by Eric Carlson.
The change in r262366 split the OpenGL work to prepare a canvas for rendering from the actual painting
(or compositing in this case). Canvas elements were being "prepared" at the end of the HTML run loop
if they'd done anything that would change pixels. The problem is that canvas elements that are not in
the document body are never composited, and thus should never be prepared, otherwise they will clear
their drawing buffer. In other words, a canvas in this state must keep the same buffer through
each rendering frame.
The solution is to check if the canvas is in the tree scope at the time we consider preparing
it for display.
* dom/Document.cpp:
(WebCore::Document::prepareCanvasesForDisplayIfNeeded):
Modified Paths
Diff
Modified: trunk/LayoutTests/platform/mac/TestExpectations (262497 => 262498)
--- trunk/LayoutTests/platform/mac/TestExpectations 2020-06-03 18:40:47 UTC (rev 262497)
+++ trunk/LayoutTests/platform/mac/TestExpectations 2020-06-03 18:48:00 UTC (rev 262498)
@@ -1964,9 +1964,6 @@
webkit.org/b/212488 [ Catalina ] media/video-play-audio-require-user-gesture.html [ Pass Timeout ]
-webkit.org/b/212594 webgl/2.0.0/conformance/canvas/buffer-offscreen-test.html [ Failure ]
-webkit.org/b/212594 webgl/1.0.3/conformance/canvas/buffer-offscreen-test.html [ Failure ]
-
# This test requires an update to system decoders
webkit.org/b/212565 [ Catalina Mojave ] imported/w3c/web-platform-tests/encoding/single-byte-decoder.html [ Failure ]
Modified: trunk/Source/WebCore/ChangeLog (262497 => 262498)
--- trunk/Source/WebCore/ChangeLog 2020-06-03 18:40:47 UTC (rev 262497)
+++ trunk/Source/WebCore/ChangeLog 2020-06-03 18:48:00 UTC (rev 262498)
@@ -1,3 +1,24 @@
+2020-06-02 Dean Jackson <[email protected]>
+
+ [ macOS ] REGRESSION(r262366): webgl/1.0.3/conformance/canvas/buffer-offscreen-test.html & webgl/2.0.0/conformance/canvas/buffer-offscreen-test.html are constant failures
+ https://bugs.webkit.org/show_bug.cgi?id=212594
+ <rdar://problem/63828783>
+
+ Reviewed by Eric Carlson.
+
+ The change in r262366 split the OpenGL work to prepare a canvas for rendering from the actual painting
+ (or compositing in this case). Canvas elements were being "prepared" at the end of the HTML run loop
+ if they'd done anything that would change pixels. The problem is that canvas elements that are not in
+ the document body are never composited, and thus should never be prepared, otherwise they will clear
+ their drawing buffer. In other words, a canvas in this state must keep the same buffer through
+ each rendering frame.
+
+ The solution is to check if the canvas is in the tree scope at the time we consider preparing
+ it for display.
+
+ * dom/Document.cpp:
+ (WebCore::Document::prepareCanvasesForDisplayIfNeeded):
+
2020-06-03 John Wilander <[email protected]>
Storage Access API: Add setting for per-page storage access scope
Modified: trunk/Source/WebCore/dom/Document.cpp (262497 => 262498)
--- trunk/Source/WebCore/dom/Document.cpp 2020-06-03 18:40:47 UTC (rev 262497)
+++ trunk/Source/WebCore/dom/Document.cpp 2020-06-03 18:48:00 UTC (rev 262498)
@@ -8587,6 +8587,13 @@
// Some canvas contexts need to do work when rendering has finished but
// before their content is composited.
for (auto* canvas : m_canvasesNeedingDisplayPreparation) {
+ // However, if they are not in the document body, then they won't
+ // be composited and thus don't need preparation. Unfortunately they
+ // can't tell at the time they were added to the list, since they
+ // could be inserted or removed from the document body afterwards.
+ if (!canvas->isInTreeScope())
+ continue;
+
auto refCountedCanvas = makeRefPtr(canvas);
refCountedCanvas->prepareForDisplay();
}
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
