From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] point2rgb and point2rgba Date: Mon, 31 Jan 2005 20:27:58 +0000 From: rog@vitanuova.com In-Reply-To: <7871fcf5050131113724b79a68@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 3ac51758-eace-11e9-9e20-41e7f4b1d025 > 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.