Salut Darin, this why I changed my initial approach (which was to send an array of smaller bitmaps alongside the array of dirty rects), to use a single bitmap with only the dirty rects drawn on it...
To overcome a weird intermittent bug I was getting with our current usage of StretchDIBits, I now use a TransportDIB that is as big as the whole view rect (as opposed to the union rect)... I think it is OK, since we use a memory pool for those and we will have done a whole view rect invalidation at least once before getting into smaller invalidation, so that should use even less memory, even though we use a bigger bitmap then needed, right? BYE MAD On Mon, May 11, 2009 at 6:26 PM, Darin Fisher <[email protected]> wrote: > On Mon, May 11, 2009 at 3:16 PM, Evan Martin <[email protected]> wrote: > > On Sat, May 9, 2009 at 10:41 AM, Darin Fisher <[email protected]> > wrote: > >>> At a high level, you're using one TransportDIB per rectangle, but it > >>> should be one per message (with multiple rects worth of image data > >>> inside). You can't really use any benchmarking results while this is > >>> the case. > >> > >> I agree. We should only require a single TransportDIB. It is > conceptually > >> just an array of pixels, so you should be able to append to that array > with > >> all of the new pixels and keep track of the offsets for each sub-bitmap. > > > > On X, the TransportDIB becomes a single Pixmap which we then bitblt > > from via X API calls. So we can't treat it *exactly* as a big array > > of pixels with offsets -- if the Pixmap is 400px wide and we have a > > tiny 20px wide dirty resize corner, we still need to write those 20px > > lines with a 400px stride. > > > > However, I think that means if you leave the TransportDIB as the union > > of all the dirty rects, everything should Just Work. So your change > > becomes sending one unioned dirty rect image of pixel data, some of > > which that may not have actually been drawn to, along with an array of > > "actually dirty" subrectangles within the image. > > > > I see.... my main concern was about wasting memory since each shared > memory allocation has significant overhead, and the minimize > allocation size is quite large, so even if you don't need much memory, > you end up using a lot of memory. > > -Darin > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
