You can get 800x600 6" displays for that price, intended as eBook reader replacement parts; a while ago someone figured out how to drive them without the official controller:

http://essentialscrap.com/eink/

That's the same model/family of panel as the one showing 32 shades of gray in this article, and the author has done some other stuff with it:

https://hackaday.io/project/11537-nekocal-an-e-ink-calendar

Unfortunately my device has only "black & white", no shades of gray at all

That's because it's a module with its own controller for producing the display driving waveforms from the 1bpp data that you feed it --- but if you disassemble the module and figure out how to drive the display itself (it's probably not unlike the link above), you could get grayscale too. In addition, you could probably stream from network to display with almost no buffering, by clocking the data directly into the display as it's received over the network (although you'd have to clear each line before drawing it; unlikely to be very difficult, in any case.) Also, refresh as fast or slow as you want.

Agreed on all counts!

I've recently picked up a e ink display with a simple passive interface board (bc Im not used to working with flex cable yet) and realized that a popular way to build the frame in the mcu memory then dump it to the board. Most hobby mcus like the atemga328p have enough static memory to store whole frames of images and then push the whole image to the display, but don't have enough dynamic memory of you want to dynamicly render whole frames and then dump them. So I think that's what you are referring to when you said your trying to figure out how render the frames without running out of memory. My screen had example code that would draw frames an push small windows of image data to the screen to draw the different parts of a complete image.

The reason I bring this up is because I recently had the idea of using small SPI flash memory chips to render the whoel.inage frame dynamicly. The SPI memory chips look like a neat way to easily do this by hooking one up to a small mcu and drawing the frame using the spi memory chop then dumping the whole frame from the memory chip to the screen. I hope to oder some small DIPs soon to experiment with and I thought it also might interest you as well.

Can you calculate it on the fly by doing a slower transfer to the display, I'm guessing it already does double buffering?

I'm not clear by what you mean; I'm new to the eink hardware scene and I don't know a lot about graphics rendering or how duble buffering works. It seems that from my understanding that you transfer the parts memory frame from the mcu to the memory on the eink display driver then you call the display driver to update the display and run the LUT tables and analog signals to do the stuff with the ink based on the current memory on the eink driver. However I am probably not right in some regards because not all eink displays have drivers and this process might not be case for all eink displays or I'm just misunderstanding how it works.

You're pretty right on all counts :)

And yet, good readers, like the ones you can use as an external display are something like $600 https://www.youtube.com/watch?v=1huyi7mgbzY