Bug 1653409 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

In order to do bug 1653048 for software-decoded video, we will need the video data in an IOSurface. Currently we have it in a shmem that gets uploaded to a GL texture via client storage.

Not all videos will be able to use the optimized path from bug 1653048. For example, videos that are subject to certain effects such as masks, 3d transforms or filters will not be able to be promoted to "compositor surfaces". For those videos we will still need a GL texture.

We can get a GL texture for an IOSurface. That means we can use the IOSurface upload path for all videos, and we can switch to it even before we do bug 1653048.

Some more relevant info from bug 1653048:
> For software decoded video and 2D canvas we currently only have a shmem. As a first step, we can do a CPU-side copy into an IOSurface in the compositor. As a second step, we should move the IOSurface closer to where the data is being generated (e.g. software video decoding) so that we can skip that copy.
> 
> We'll also need to keep in mind the buffer lifetimes. Giving an IOSurface to the window server means that the IOSurface content must not be touched until the window server is done with it. In the past, WR was doing a copy during the composite, so the IOSurface could be unlocked right after that composite. But now it will need to stay locked for longer.
In order to do bug 1653048 for software-decoded video, we will need to have the video data in an IOSurface. Currently we have it in a shmem that gets uploaded to a GL texture via client storage.

Not all videos will be able to use the optimized path from bug 1653048. For example, videos that are subject to certain effects such as masks, 3d transforms or filters will not be able to be promoted to "compositor surfaces". For those videos we will still need a GL texture.

We can get a GL texture for an IOSurface. That means we can use the IOSurface upload path for all videos, and we can switch to it even before we do bug 1653048.

Some more relevant info from bug 1653048:
> For software decoded video and 2D canvas we currently only have a shmem. As a first step, we can do a CPU-side copy into an IOSurface in the compositor. As a second step, we should move the IOSurface closer to where the data is being generated (e.g. software video decoding) so that we can skip that copy.
> 
> We'll also need to keep in mind the buffer lifetimes. Giving an IOSurface to the window server means that the IOSurface content must not be touched until the window server is done with it. In the past, WR was doing a copy during the composite, so the IOSurface could be unlocked right after that composite. But now it will need to stay locked for longer.
In order to do bug 1653048 for software-decoded video, we will need to have the video data in an IOSurface. Currently we have the data in a shmem, and the data gets uploaded to a GL texture via client storage.

Not all videos will be able to use the optimized path from bug 1653048. For example, videos that are subject to certain effects such as masks, 3d transforms or filters will not be able to be promoted to "compositor surfaces". For those videos we will still need a GL texture.

We can get a GL texture for an IOSurface. That means we can use the IOSurface upload path for all videos, and we can switch to it even before we do bug 1653048.

Some more relevant info from bug 1653048:
> For software decoded video and 2D canvas we currently only have a shmem. As a first step, we can do a CPU-side copy into an IOSurface in the compositor. As a second step, we should move the IOSurface closer to where the data is being generated (e.g. software video decoding) so that we can skip that copy.
> 
> We'll also need to keep in mind the buffer lifetimes. Giving an IOSurface to the window server means that the IOSurface content must not be touched until the window server is done with it. In the past, WR was doing a copy during the composite, so the IOSurface could be unlocked right after that composite. But now it will need to stay locked for longer.

Back to Bug 1653409 Comment 0