Seems like it is more efficient to let the texturemapper handle video rotation. Sadly this currently breaks media/video-orientation-canvas.html as shown in the attached screenshot.
Created attachment 427883 [details]
I guess glvideoflip is performing a texture copy to perform the rotation, which is not as efficient as doing it ourselves when painting the frame (we save a copy).
I assume the same happens with the videflip element: a copy is performed in order to get the rotated frame.
IMO we should get rid of both videoflip and glvideoflip, and always perform the rotation ourselves: better performance (save a copy) and simpler code (a single case to handle).
I wonder what's the performance impact of glvideoflip. Internally it uses this element:
Anyways, I agree if can do all the things with the texturemapper it's nicer.
(In reply to Philippe Normand from comment #3)
> I wonder what's the performance impact of glvideoflip. Internally it uses
> this element:
As expected, it's a texture copy using a shader that performs the rotation. I can't say exactly, but I recall seeing this operations taking around 1-2ms on the rpi2 (more on bigger resolutions). This may not seem a lot, but when rendering at 60fps we only have 16ms to render each frame, those ms count. Also, the OpenGL pipeline is a shared resource, and the time spent rotating the frames is time that is not used rendering other stuff.
> Anyways, I agree if can do all the things with the texturemapper it's nicer.
Let me cook a patch for that.
Created attachment 430458 [details]
Committed r278406 (238431@main): <https://commits.webkit.org/238431@main>
All reviewed patches have been landed. Closing bug and clearing flags on attachment 430458 [details].