>
> 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.
>

This is exactly what I'm doing on Windows... The receiving side loops on the
dirty sub-rectangles and get their pixels from the single btimap being
sent... And this bitmap is "only" valid in the areas of the sub-rectangles
passed in a vector via IPC.

Are we saying the same thing here?
BYE
MAD
P.S.: I'm still validating that it is all OK on the Windows side, just fixed
what I hope was the last refresh bug with Google maps, and then, I'll update
the GTK and Coco version of the painting code...

On Mon, May 11, 2009 at 6: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.
>

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to