Pathfinder and its ilk would breeze through this sort of thing, and are still improving constantly too, because so comparatively little work has been done in the space.
Guessing very roughly based on the figures in https://raphlinus.github.io/rust/graphics/gpu/2020/06/13/fas... (and Pathfinder is integrating some of the techniques there), I’d estimate that piet-gpu and soon Pathfinder, running on Intel integrated graphics, could comfortably draw each frame of this Simpsons sample video in well under one millisecond (for an effective maximum of 6% GPU/CPU usage), probably even under a tenth of a millisecond (0.6%).
(Admittedly you could easily create a more complicated video which would be much more draining, e.g. paris-30k frames would struggle to hit 120fps on integrated graphics. Generally speaking it’s easier to make pathological cases in vector encodings than raster. But let’s forget about that.)
At that point, the hardware separation of video decoder and other graphics stuff (which is a strong point in general, because it’s so computationally expensive) is much less important.
You speak of Pathfinder and Slug as being “very complicated”, and indeed they are; but video decoding is hardly any less complicated, and much more computationally expensive.
Raph's technique relies on compute shaders as a core part of the processing technique. That wouldn't work on an overwhelming majority of phones these days. Pathfinder has a compute-less approach which moves the binning to the CPU, not the GPU. And we're talking about bandwidth-constrained devices. I don't think you're going to out-perform H264.
Slug is not applicable to this scene -- it makes several core operating assumptions (being able to pre-process curve data into a friendlier format, and its shape bounding boxes are well-defined and pre-processed. These hold for font / text assets but not real-time glyphs)
Video decoding is computationally expensive, but it's done by dedicated silicon on most modern GPUs in order to deliver better battery life and better performance. So is encoding. Dedicated silicon is what these other techniques have to compete with - certainly possible, but not easy.
It’s done in dedicated silicon in order to deliver better battery life and better performance, given how extremely computationally expensive it is.
Playing back vector video is simply much less expensive, as it’s doing much less work. Assuming content like the sample videos here, I would expect vector video to be immediately competitive with raster video codecs in power efficiency and performance, once you shift the bulk of the vector rendering from CPU to GPU.
Guessing very roughly based on the figures in https://raphlinus.github.io/rust/graphics/gpu/2020/06/13/fas... (and Pathfinder is integrating some of the techniques there), I’d estimate that piet-gpu and soon Pathfinder, running on Intel integrated graphics, could comfortably draw each frame of this Simpsons sample video in well under one millisecond (for an effective maximum of 6% GPU/CPU usage), probably even under a tenth of a millisecond (0.6%).
(Admittedly you could easily create a more complicated video which would be much more draining, e.g. paris-30k frames would struggle to hit 120fps on integrated graphics. Generally speaking it’s easier to make pathological cases in vector encodings than raster. But let’s forget about that.)
At that point, the hardware separation of video decoder and other graphics stuff (which is a strong point in general, because it’s so computationally expensive) is much less important.
You speak of Pathfinder and Slug as being “very complicated”, and indeed they are; but video decoding is hardly any less complicated, and much more computationally expensive.