Branch: refs/heads/webkitglib/2.46
Home: https://github.com/WebKit/WebKit
Commit: bd8e4fbbde0eb00ef8d2a2ef7cb6c74f3c763d19
https://github.com/WebKit/WebKit/commit/bd8e4fbbde0eb00ef8d2a2ef7cb6c74f3c763d19
Author: Carlos Alberto Lopez Perez <[email protected]>
Date: 2024-11-26 (Tue, 26 Nov 2024)
Changed paths:
M Source/WebCore/dom/wpe/PointerEventWPE.cpp
M Source/WebKit/Shared/libwpe/WebEventFactory.cpp
M Tools/PlatformWPE.cmake
M Tools/wpe/backends/fdo/WindowViewBackend.cpp
M Tools/wpe/backends/fdo/WindowViewBackend.h
Log Message:
-----------
Cherry-pick 287077@main (363198dfec40).
https://bugs.webkit.org/show_bug.cgi?id=270516
REGRESSION(263237@main): [WPE] Identifiers for touch points are not
constant in multi touch
https://bugs.webkit.org/show_bug.cgi?id=270516
Reviewed by Adrian Perez de Castro.
263237@main implemented tracking of touchstart/touchend events in order to
guess when a new touchpoint was pressed and assign a unique ID to each.
The issue here is that doesn't work well in practice.
I'm not sure if is because of buggy drivers or buggy devices, but it happens
that sometimes when we start a new touch event (put a new finger on the
screen)
without removing the previous ones we can receive more than one touchstart
event
(one for the ongoing gesture and one for the new).
There are also issues when trying to use several fingers at the same time
on some
touchscreens that do not properly support that like dual-touch devices, in
that
case we may receive several touchstart events (more than two) and perhaps
some fake
touchend events (or missing touchend events) and that will end confusing
the logic.
So instead of trying to implement in WebKit code the tracking of the
touchpoints
is better that we rely on the system (the driver, libinput and the
wayland-protocol)
to track the touchpoints for us.
The touch IDs that we receive from the system are already unique from the
other
ones active at that moment, each active touchpoint should have a different
ID.
So, there isn't really a need to assign random IDs by ourselves.
However, the IDs that we receive from the system for the touchpoints start
at 0, but IDs 0 and 1 are already reserved for the mouse and the stylus
pointer devices. So to ensure that the ID of the touchpoint will be unique
we can simply add 2 to the value from the system.
Note also what the PointerEvents spec says
<https://www.w3.org/TR/pointerevents/>:
> pointerId is a unique identifier for the pointer causing the event.
> This identifier MUST be unique from all other active pointers in the
top-level
> browsing context (as defined by [HTML5]) at the time.
> A user agent MAY recycle previously retired values for pointerId from
previous
> active pointers, if necessary.
So the ID has to be unique only between the active ones, and that is what
we get from the system.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/gtk/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebCore/dom/wpe/PointerEventWPE.cpp:
* Source/WebKit/Shared/libwpe/WebEventFactory.cpp:
(WebKit::WebEventFactory::createWebTouchEvent):
* Tools/PlatformWPE.cmake:
* Tools/wpe/backends/fdo/WindowViewBackend.cpp:
* Tools/wpe/backends/fdo/WindowViewBackend.h:
Canonical link: https://commits.webkit.org/287077@main
Canonical link: https://commits.webkit.org/282416.324@webkitglib/2.46
Commit: bb931888de867e61e684aa04f5335f107f33a047
https://github.com/WebKit/WebKit/commit/bb931888de867e61e684aa04f5335f107f33a047
Author: Diego Pino Garcia <[email protected]>
Date: 2024-11-26 (Tue, 26 Nov 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp
Log Message:
-----------
Cherry-pick 286530@main (9148a433d502).
https://bugs.webkit.org/show_bug.cgi?id=270638
[GCC] Unreviewed, build fix for Debian-12 ARM32 after 286527@main
https://bugs.webkit.org/show_bug.cgi?id=270638
GCC-12 returned a build error:
error: invalid cast from type 'size_t' {aka 'unsigned int'} to type
'WebCore::TrackID'
Replace 'reinterpret_cast' for 'static_cast' since both types
are compatible.
* Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:
Canonical link: https://commits.webkit.org/286530@main
Canonical link: https://commits.webkit.org/282416.325@webkitglib/2.46
Commit: aa89e2e0031d53f49673b9a31d8116e8df2d5670
https://github.com/WebKit/WebKit/commit/aa89e2e0031d53f49673b9a31d8116e8df2d5670
Author: Philippe Normand <[email protected]>
Date: 2024-11-26 (Tue, 26 Nov 2024)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h
M Source/WebCore/platform/graphics/gstreamer/VideoFrameMetadataGStreamer.cpp
Log Message:
-----------
Cherry-pick 287084@main (1ce41f04b775).
https://bugs.webkit.org/show_bug.cgi?id=283457
[GStreamer] Tests using requestVideoFrameCallback on a paused element are a
constant failure
https://bugs.webkit.org/show_bug.cgi?id=283457
Reviewed by Xabier Rodriguez-Calvar.
There were two issues here:
- The preroll buffer is reported twice by appsink, once with the preroll
signal and once right after
the preroll signal. So this needs to be taken into account when filling
rvfc metadata.
- In case the negotiated framerate is variable buffer duration might not be
filled in buffers, so as
a workaround it is estimated from the first buffer PTS. It's not perfect
but it is better than
nothing.
* LayoutTests/platform/glib/TestExpectations:
*
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::pushTextureToCompositor):
(WebCore::MediaPlayerPrivateGStreamer::triggerRepaint):
(WebCore::MediaPlayerPrivateGStreamer::videoFrameMetadata):
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
*
Source/WebCore/platform/graphics/gstreamer/VideoFrameMetadataGStreamer.cpp:
(webkitGstBufferGetVideoFrameMetadata):
Canonical link: https://commits.webkit.org/287084@main
Canonical link: https://commits.webkit.org/282416.326@webkitglib/2.46
Commit: 239369ca3cb734daeab7520f7c9d26a90b88c524
https://github.com/WebKit/WebKit/commit/239369ca3cb734daeab7520f7c9d26a90b88c524
Author: Philippe Normand <[email protected]>
Date: 2024-11-26 (Tue, 26 Nov 2024)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp
Log Message:
-----------
Cherry-pick 287086@main (581187275fde).
https://bugs.webkit.org/show_bug.cgi?id=283666
[GStreamer][MediaRecorder] Support for the isofmp4 muxer
https://bugs.webkit.org/show_bug.cgi?id=283666
Reviewed by Xabier Rodriguez-Calvar.
The isofmp4mux is able to write an mfra box at EOS, containing the total
duration of the media. The
mp4mux doesn't seem to implement that properly. So if the fmp4 plugin is
available, make sure the
isofmp4mux element is auto-plugged by transcodebin.
* Source/WebCore/platform/graphics/gstreamer/GStreamerCommon.cpp:
(WebCore::registerWebKitGStreamerElements):
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp:
(WebCore::MediaRecorderPrivateBackend::containerProfile):
Canonical link: https://commits.webkit.org/287086@main
Canonical link: https://commits.webkit.org/282416.327@webkitglib/2.46
Compare: https://github.com/WebKit/WebKit/compare/0c60a2686f3d...239369ca3cb7
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
