Branch: refs/heads/webkitglib/2.42
Home: https://github.com/WebKit/WebKit
Commit: 62c5bb27a938b55f679c503293fa0a0bc6058581
https://github.com/WebKit/WebKit/commit/62c5bb27a938b55f679c503293fa0a0bc6058581
Author: Carlos Garcia Campos <cgar...@igalia.com>
Date: 2023-09-08 (Fri, 08 Sep 2023)
Changed paths:
M
Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp
M
Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.h
M Source/WebKit/UIProcess/DrawingAreaProxy.messages.in
M
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp
M
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.messages.in
Log Message:
-----------
Cherry-pick 267399@main (3e47e6d0c366).
https://bugs.webkit.org/show_bug.cgi?id=259647
REGRESSION(263118@main): [CoordinatedGraphics] Incomplete rendering after
10s inactivity without hardware acceleration
https://bugs.webkit.org/show_bug.cgi?id=260505
Reviewed by Michael Catanzaro.
When the backing store is discarded in the UI process we need to notify
the web process to reset the dirty region to the entire web view and
ensure next update is not partial. This avoids flickering and ensures a
full update of the view when a new backing store is created. We should
also avoid flickering when forcing an update, by waiting for the Update
message synchronously.
*
Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp:
(WebKit::DrawingAreaProxyCoordinatedGraphics::paint):
(WebKit::DrawingAreaProxyCoordinatedGraphics::forceUpdateIfNeeded):
(WebKit::DrawingAreaProxyCoordinatedGraphics::incorporateUpdate):
(WebKit::DrawingAreaProxyCoordinatedGraphics::enterAcceleratedCompositingMode):
(WebKit::DrawingAreaProxyCoordinatedGraphics::discardBackingStore):
*
Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.h:
* Source/WebKit/UIProcess/DrawingAreaProxy.messages.in:
*
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
(WebKit::DrawingAreaCoordinatedGraphics::updateGeometry):
(WebKit::DrawingAreaCoordinatedGraphics::didDiscardBackingStore):
*
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h:
* Source/WebKit/WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::didDiscardBackingStore):
* Source/WebKit/WebProcess/WebPage/DrawingArea.messages.in:
Canonical link: https://commits.webkit.org/267399@main
Commit: 22fa146615f05821dcbad98a80837f1cc54b77fa
https://github.com/WebKit/WebKit/commit/22fa146615f05821dcbad98a80837f1cc54b77fa
Author: Carlos Garcia Campos <cgar...@igalia.com>
Date: 2023-09-08 (Fri, 08 Sep 2023)
Changed paths:
M
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp
M
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.h
Log Message:
-----------
Cherry-pick 267733@main (44051cb8e33a).
https://bugs.webkit.org/show_bug.cgi?id=261273
REGRESSION(262812@main): No render updates after cross origin history
navigation
https://bugs.webkit.org/show_bug.cgi?id=261273
Reviewed by Michael Catanzaro.
This regressed in 262812@main because we moved the code to enter AC mode
when always compositing to the DrawingArea constructor to make sure the
UI process starts receiving IPC messages for the new drawing area as
soon as possible after a drawing area switch due to cross origin
navigation. The problem now is when going back after a cross origin
navigation because there's a display refresh monitor switch too, but to
create the proper display refresh monitor we need an already created
drawing area, since WebChromeClient::displayRefreshMonitorFactory()
returns the WebPage drawing area, not yet set during its constructor.
So, we need to enter AC mode right after the drawing area is created
instead of in the constructor to ensure the right display refresh
monitor is created. This doesn't fail in GTK3 because we create a
DisplayRefreshMonitorGtk, but that's not the right one either, since
it's expected to be used only for non-AC mode.
*
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
(WebKit::DrawingAreaCoordinatedGraphics::DrawingAreaCoordinatedGraphics):
(WebKit::DrawingAreaCoordinatedGraphics::enterAcceleratedCompositingModeIfNeeded):
*
Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h:
* Source/WebKit/WebProcess/WebPage/DrawingArea.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::m_appHighlightsVisible):
(WebKit::WebPage::reinitializeWebPage):
* Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.h:
Canonical link: https://commits.webkit.org/267733@main
Commit: 56f0f3882de8cede7ae22385938c1f0c7edebf3f
https://github.com/WebKit/WebKit/commit/56f0f3882de8cede7ae22385938c1f0c7edebf3f
Author: Philippe Normand <ph...@igalia.com>
Date: 2023-09-08 (Fri, 08 Sep 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/ImageGStreamer.h
M Source/WebCore/platform/graphics/gstreamer/ImageGStreamerCairo.cpp
M Source/WebCore/platform/graphics/gstreamer/VideoDecoderGStreamer.cpp
Log Message:
-----------
Cherry-pick 267132@main (dfa421425d51).
https://bugs.webkit.org/show_bug.cgi?id=260423
[GStreamer][WebCodecs] Circular references in video decoder leading to
memory leaks
https://bugs.webkit.org/show_bug.cgi?id=260423
Reviewed by Xabier Rodriguez-Calvar.
Circular references between the GStreamerInternalVideoDecoder and its
harness through captured
references in lambdas was preventing proper cleanup of the harness when
closing the decoder. Using
WeakPtrs instead of strong Refs in captured variables fixes the issue.
Also, driving-by, fixing the ImageGStreamer API to fit with our style
guidelines and making sure the
sample is cleared *after* the associated video frame is un-mapped.
* Source/WebCore/platform/graphics/gstreamer/ImageGStreamer.h:
(WebCore::ImageGStreamer::createImage):
* Source/WebCore/platform/graphics/gstreamer/ImageGStreamerCairo.cpp:
(WebCore::ImageGStreamer::~ImageGStreamer):
* Source/WebCore/platform/graphics/gstreamer/VideoDecoderGStreamer.cpp:
(WebCore::GStreamerInternalVideoDecoder::harnessedElement const):
(WebCore::GStreamerVideoDecoder::create):
(WebCore::GStreamerVideoDecoder::~GStreamerVideoDecoder):
(WebCore::GStreamerInternalVideoDecoder::GStreamerInternalVideoDecoder):
(WebCore::GStreamerInternalVideoDecoder::decode):
Canonical link: https://commits.webkit.org/267132@main
Commit: 02d362b73707c6caa4fb92cceb883d198b4f7304
https://github.com/WebKit/WebKit/commit/02d362b73707c6caa4fb92cceb883d198b4f7304
Author: Enrique Ocaña González <eoca...@igalia.com>
Date: 2023-09-08 (Fri, 08 Sep 2023)
Changed paths:
M
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 267276@main (5023d703877c).
https://bugs.webkit.org/show_bug.cgi?id=260067
[MSE][GStreamer] Deadlock while flushing on paused when there's a non
in-place transform element
https://bugs.webkit.org/show_bug.cgi?id=260067
Reviewed by Alicia Boya Garcia.
There is a deadlock possible inside WebKit media src (MSE) between
streaming thread handling
CAPS event and pipeline flush in the main thread. This happens in case
where there is a
transform element in the pipeline that does transition NOT in place.
Basetransform elem
expects that it will allocate buffers so on CAPS change it triggers
allocation negotiations
(ALLOCATION query). In such case CAPS event becomes fully synchronous as
basetransform does
ALLOCATION query that is synchronous (serialized with data) and may block
the streaming
thread. If the pipeline is paused and the sink thread doesn't accept any
data, this will
block CAPS event until pipeline is unpaused or flushed. But flush requires
a lock that
streaming thread is holding (DataMutexLocker streamingMembers {
stream->streamingMembersDataMutex };)
See: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1135
A way to fix this is to make webKitMediaSrcLoop() release the lock before
pushing the caps
event (which may take a long time to get processed) to let the main thread
start the flush.
Such a flush would cause the sink element to release the streaming thread
and the caps event
processing to finish. After the caps event has been pushed, the lock would
be retaken. But
streamingMembers might have changed under our feet (and it certainly will,
because of the
flush). We should reevaluate if the flush condition is present, and in that
case abort the
execution of webKitMediaSrcLoop() after having paused the streaming task of
the
corresponding pad.
*
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
(webKitMediaSrcLoop): Run the caps pushing code with the lock released and
reevaluate the flush condition after the lock is reacquired.
Canonical link: https://commits.webkit.org/267276@main
Commit: 8f58a5833296d21aff427088a0789aaafc36bcb0
https://github.com/WebKit/WebKit/commit/8f58a5833296d21aff427088a0789aaafc36bcb0
Author: Philippe Normand <ph...@igalia.com>
Date: 2023-09-08 (Fri, 08 Sep 2023)
Changed paths:
A LayoutTests/http/wpt/mediarecorder/MediaRecorder-start-stop-crash.html
M Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.h
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.h
Log Message:
-----------
Cherry-pick 267345@main (37bc74274076).
https://bugs.webkit.org/show_bug.cgi?id=260649
[GStreamer] Prevent a crash when fetching data on stopped MediaRecorder
https://bugs.webkit.org/show_bug.cgi?id=260649
rdar://problem/114370120
Reviewed by Xabier Rodriguez-Calvar.
The backend (GStreamer transcoder) is now clearly separated from the
MediaRecorderPrivate, so that
fetchData() can create a weak pointer to be used from the main thread. If
the backend was destroyed
in-flight no unsafe memory access is performed.
Test: http/wpt/mediarecorder/MediaRecorder-start-stop-crash.html
Canonical link: https://commits.webkit.org/267345@main
Commit: 4de1c4bdd98d1550f4374e77a0fb1f7aa608a21f
https://github.com/WebKit/WebKit/commit/4de1c4bdd98d1550f4374e77a0fb1f7aa608a21f
Author: Philippe Normand <ph...@igalia.com>
Date: 2023-09-08 (Fri, 08 Sep 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/VideoFrameGStreamer.cpp
Log Message:
-----------
Cherry-pick 267347@main (0b71df88d472).
https://bugs.webkit.org/show_bug.cgi?id=260713
[GStreamer] VideoFrame metadata not explicitely updated in underlying sample
https://bugs.webkit.org/show_bug.cgi?id=260713
Reviewed by Xabier Rodriguez-Calvar.
Update the sample in case its buffer received additional metadata.
* Source/WebCore/platform/graphics/gstreamer/VideoFrameGStreamer.cpp:
(WebCore::VideoFrameGStreamer::VideoFrameGStreamer):
Canonical link: https://commits.webkit.org/267347@main
Commit: 8f9cb073220025ea7de436dc3bbeb86817a97c44
https://github.com/WebKit/WebKit/commit/8f9cb073220025ea7de436dc3bbeb86817a97c44
Author: Philippe Normand <ph...@igalia.com>
Date: 2023-09-08 (Fri, 08 Sep 2023)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 267663@main (9c3e31205a2d).
https://bugs.webkit.org/show_bug.cgi?id=261144
[GStreamer] Missing check on mapped video frame validity before pushing to
compositor
https://bugs.webkit.org/show_bug.cgi?id=261144
Reviewed by Xabier Rodriguez-Calvar.
Exit early from the pushDMABufToCompositor() method if we failed to map the
video frame. No need for
a dedicated warning, there is one already in gst_video_frame_map().
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):
Canonical link: https://commits.webkit.org/267663@main
Compare: https://github.com/WebKit/WebKit/compare/d3d4dad6e880...8f9cb0732200
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
