On Mon, May 11, 2009 at 3:16 PM, Evan Martin <e...@chromium.org> wrote:
> On Sat, May 9, 2009 at 10:41 AM, Darin Fisher <da...@chromium.org> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
