WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
237034
REGRESSION(
r290175
): Texture upload from video and user media is slower than expected for non-GPUP WebGL
https://bugs.webkit.org/show_bug.cgi?id=237034
Summary
REGRESSION(r290175): Texture upload from video and user media is slower than ...
Kimmo Kinnunen
Reported
2022-02-22 05:51:09 PST
REGRESSION(
r290175
): Texture upload from video and user media is slower than expected for non-GPUP WebGL
Attachments
Patch
(7.67 KB, patch)
2022-02-22 05:53 PST
,
Kimmo Kinnunen
no flags
Details
Formatted Diff
Diff
Patch for landing
(7.65 KB, patch)
2022-02-23 01:12 PST
,
Kimmo Kinnunen
no flags
Details
Formatted Diff
Diff
Patch for landing
(7.85 KB, patch)
2022-02-23 02:23 PST
,
Kimmo Kinnunen
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Kimmo Kinnunen
Comment 1
2022-02-22 05:53:14 PST
Created
attachment 452857
[details]
Patch
youenn fablet
Comment 2
2022-02-22 06:09:23 PST
Comment on
attachment 452857
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=452857&action=review
> Source/WebKit/WebProcess/GPU/media/RemoteVideoFrameProxy.cpp:123 > + auto result = m_connection->sendSync(Messages::RemoteVideoFrameObjectHeap::PixelBuffer(read()), Messages::RemoteVideoFrameObjectHeap::PixelBuffer::Reply(pixelBuffer), 0, defaultTimeout);
I would tend to move that code in RemoteVideoFrameObjectHeapProxy instead of here. At some point, I think we should also go through RemoteVideoFrameObjectHeapProxy to release the video frame. Then RemoteVideoFrameProxy would not need to have a m_connection, nor do any direct IPC, the heap proxy would do it.
> Source/WebKit/WebProcess/GPU/media/RemoteVideoFrameProxy.h:97 > + static inline Seconds defaultTimeout = 10_s;
10_s seems like a lot of time. It probably does not matter right now since all our frames are created in GPUProcess so value could be 0_s.
youenn fablet
Comment 3
2022-02-22 06:13:25 PST
Comment on
attachment 452857
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=452857&action=review
> Source/WebKit/WebProcess/GPU/media/RemoteVideoFrameProxy.cpp:125 > + return nullptr;
If there is no result, we should probably create a black pixel buffer, so that libwebrtc is made happy.
Kimmo Kinnunen
Comment 4
2022-02-23 00:52:19 PST
Comment on
attachment 452857
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=452857&action=review
thanks!
>> Source/WebKit/WebProcess/GPU/media/RemoteVideoFrameProxy.cpp:123 >> + auto result = m_connection->sendSync(Messages::RemoteVideoFrameObjectHeap::PixelBuffer(read()), Messages::RemoteVideoFrameObjectHeap::PixelBuffer::Reply(pixelBuffer), 0, defaultTimeout); > > I would tend to move that code in RemoteVideoFrameObjectHeapProxy instead of here. > At some point, I think we should also go through RemoteVideoFrameObjectHeapProxy to release the video frame. > Then RemoteVideoFrameProxy would not need to have a m_connection, nor do any direct IPC, the heap proxy would do it.
Talked offline. Currently it's one message, so it doesn't need state stored in proxy. The current functionality of the proxy itself should be removed once the IPC system is improved to not require such duplicated code for sending big blocks of memory.
>> Source/WebKit/WebProcess/GPU/media/RemoteVideoFrameProxy.cpp:125 >> + return nullptr; > > If there is no result, we should probably create a black pixel buffer, so that libwebrtc is made happy.
done
Kimmo Kinnunen
Comment 5
2022-02-23 01:12:41 PST
Created
attachment 452950
[details]
Patch for landing
Kimmo Kinnunen
Comment 6
2022-02-23 02:23:04 PST
Created
attachment 452954
[details]
Patch for landing
EWS
Comment 7
2022-02-23 22:37:08 PST
Committed
r290413
(
247721@main
): <
https://commits.webkit.org/247721@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 452954
[details]
.
Radar WebKit Bug Importer
Comment 8
2022-02-23 22:38:21 PST
<
rdar://problem/89400347
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug