Re: [9fans] point2rgb and point2rgba

[rog@vitanuova.com]

> Does the current draw device penalize these operations so much?

i believe so.  (particularly if you're doing lots of small scattered
updates to a largish image).

say you've got some software which maintains its own client-side
bitmap.  for each rectangle to be updated, you've got to copy the bits
for that rectangle into a buffer(*), invoke loadimage, which copies the
data into another buffer (with at least 21 extra), invokes a write
syscall (one for each 64K of data), which copies the data into the destination image.

since the display can be in any channel format, and one generally
wants to avoid code bloat, it's not uncommon to have the destination
image actually be an intermediate image in a known pixel format, which
is then actually copied onto an on-screen image.

if you could get the draw device to create an image to which there was
shared-memory access, all but the last step could be eliminated.
i reckon this could speed things up a lot, but i haven't measured it,
so it's quite possible i'm totally misguided.

(*) one way to eliminate one data copy in the above scenario might be to
give loadimage a "skip" argument (a number of bytes in the data to
skip after each line).  then at least you could do loadimage directly
from the client-side image data. this wouldn't affect the anything
if you're always blitting the whole image.