Supporting electronic paper [LWN.net]

Supporting electronic paper

Posted Nov 23, 2007 9:55 UTC (Fri) by nlucas (subscriber, #33793)
Parent article: Supporting electronic paper

One thing I noticed when working on a prototype to a virtual display driver (same problems, if
you can't write directly on the graphic card frame buffer), was that if you have a big latency
but have enough bandwidth, it may be cheaper to do the deferred write to all the pages,
instead of controlling what different pages changed.

In the case of a virtual driver, if you have a modern graphic card on the host side, it will
not be noticeable in speed if you do 640x480, 800x600 or a 1024x768 blit, but it will be
noticeable if you do a sequence of smaller blits to changed parts of the screen (making it
ugly).

(Log in to post comments)

Supporting electronic paper

Posted Nov 30, 2007 2:05 UTC (Fri) by jayakumar (guest, #49119) [Link]

> In the case of a virtual driver, if you have a modern graphic card on the host side, it will
> not be noticeable in speed if you do 640x480, 800x600 or a 1024x768 blit, but it will be
> noticeable if you do a sequence of smaller blits to changed parts of the screen (making it
> ugly).

I'm not sure but I think you are referring to "tearing" right? ie: on a normal display (LCD or
CRT), if you're updating parts of the display during the retrace, then you would get tearing
if the part that was changing was part of an overall image. For example, if I was spinning a
globe on the display and then updating parts of the globe map without syncing to retrace, I
would get tearing which is what I understand when you say "making it ugly". This imposes the
need for synchronization with the vertical blanking interval. In the case of E-paper, there is
no retrace, and it is currently too slow to use for over 4Hz, so a partial display update is
ok because its unlikely to be used for moving images. I hope I have understood you correctly.
Thanks.