As an intermediate point of reference, looking at the calls
to RenderWidget::DidInvalidateRect() and tracing the cases where the new
rect doesn't intersect with the current paint_rect, I get the following
results:
Without the resizer rect:
(0, 0, 743, 633) not in (0, 0, 0, 0)
(362, 8, 1, 1) not in (0, 0, 0, 0)
(726, 0, 17, 609) not in (0, 0, 0, 0)
(0, 0, 17, 17) not in (0, 0, 0, 0)
With the resizer rect:
(0, 0, 743, 633) not in (0, 0, 0, 0)
(362, 8, 1, 1) not in (0, 0, 0, 0)
(726, 0, 17, 592) not in (0, 0, 0, 0)
(726, 592, 17, 17) not in (0, 0, 0, 0)
(0, 0, 17, 17) not in (726, 592, 17, 17)
(21, 149, 12, 25) not in (0, 0, 0, 0)
So we do get a few more, and the scariest is the second last one, where
we get the two extreme corners of the window... I'll try to see if this
could actually be a bug where the position of the invalidation is wrong and
the intent was to get it at (726, 592) but it wasn't offset properly... But
since we also have that same (0, 0, 17, 17) request in the no resizer rect
scenario, I doubt it...
Otherwise, I'll try to compute the timings with a new paint message that
receives an array of rects instead of a union...
BYE
MAD
On Thu, Apr 30, 2009 at 1:59 PM, Marc-Andre Decoste <m...@chromium.org>wrote:
> Salut Adam,
> this is a theory that I'm currently validating... And I will try to
> change the IPC message code to confirm that it will resolve the problem...
> So I guess you don't see any problem in this approach... So if I succeed,
> now I know who to ask for a code review :-)
>
> Thanks!
>
> BYE
> MAD
>
>
> On Thu, Apr 30, 2009 at 1:44 PM, Adam Langley <a...@chromium.org> wrote:
>
>> On Thu, Apr 30, 2009 at 7:51 AM, Marc-Andre Decoste <m...@chromium.org>
>> wrote:
>> > An alternative could be to send a bitmap the size of the union rect,
>> but
>> > only paint the individual rects in it, and extract them individually on
>> the
>> > other side of the IPC... But I wonder if it would be worth the added
>> > complexity and risk... Unless I missed something (which is most probably
>> the
>> > case :-)...
>>
>> Forgive me if I'm misunderstanding here. But is the problem that the area
>> of the
>> union rectangle is significantly greater than the areas of the actually
>> damaged
>> regions, thus we're painting too much?
>>
>> If that's the case, we could well change the PaintRect and ScrollRect
>> messages
>> to carry a vector of rects and have them arranged in sequence in the
>> TransportDIB. Since I'm currently to blame for much of the IPC painting
>> code, I
>> can do this if it'll be of benefit.
>>
>>
>> AGL
>>
>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
