Because of what was mentioned way up in the original question: The capsules not being precisely arranged means that they can't be individually addressable. Meaning that you can't use the trick that non-epaper screens typically use where each "pixel" is actually a tightly packed cluster of individual red, green and blue sources that are individually controlled.
So instead, each cell is capable of displaying any color, and they've got a more complicated refresh mechanism that they use to "write" to them.
And the upshot of that is listed in the specifications from the linked page: The refresh time on this display is 15 seconds. Which is far, far away from where it would need to be in order to be a practical option for color e-readers.
I have the 2.7” 3 color (b) hat, and it is very slow with stock code. As far as I know, and from the looks of the Python code, 2 full buffers are transferred for the colors and then a process of wave stimulating the fluids into arrangement are how it works, very conservatively and slow. There has been work done to the firmware to allow partial updates fast enough for animation, but they should be used sparingly to avoid temporary or permanent burn-in, they say.
> Meaning that you can't use the trick that non-epaper screens typically use where each "pixel" is actually a tightly packed cluster of individual red, green and blue sources that are individually controlled
If there was a way to mix the inks and have them 100% separate by the grid on demand, it could be possible.
So instead, each cell is capable of displaying any color, and they've got a more complicated refresh mechanism that they use to "write" to them.
And the upshot of that is listed in the specifications from the linked page: The refresh time on this display is 15 seconds. Which is far, far away from where it would need to be in order to be a practical option for color e-readers.