One of the weird things is that writing to the framebuffer can be surprisingly slow. At least I've seen it in practice where a machine that can play a video just fine in X maxes out the CPU and drops frames when trying to write directly to the framebuffer. It seems like it should be the opposite and since it was just something I was trying out for fun I didn't dive too deeply into figuring out what was going on. It may have been something like X was using GPU accel or the video player was writing to the framebuffer in an inefficient way (one write call per pixel) or something.
For most video cards and driver combinations, the fbdev interface is an emulated, legacy interface. DRI and X have the intended fast path to the device, and you have to jump through some hoops to get to an API and handle that behaves like mmap'd /dev/fbX.
> writing to the framebuffer in an inefficient way
Fun fact you can memory map /dev/fb0 and make changes to it directly.
Decoding video frames is much more expensive, than rendering them. The source of the slowdown could be software decoding the video frame. Where the X video player might have been using a specialized chip for this, i.e. GPU or Intel graphics, depending on the setup.
