Salut again, I got a bit further, but not quite there yet... The (0, 0, 17, 17) invalidation request came from the fact that WebKit invalidates the scroll bars when their enabled state is set, and it was done "before" the frame rect of the scroll bar is set... So I fixed that (by simply reversing the call order) and so we save a few extraneous invalidations less... But that didn't make much of a difference in the timing unfortunately.
Then I tried to pass an array of bitmaps and rects (as opposed to a union of rects) to the paint rect IPC message, and it cut off 100ms of my 3.2 seconds scenario (so down to 3.1s), but it also cuts off some time off of the scenario without the resizer rect (which went from about 2.72s to roughly 2.68s)... So these don't seem to be THE reason for this slow down... So I keep digging... But I wonder if it would be worth it or not to commit these changes anyway, since they do provide a small performance improvement (at least in the scenario I'm working with, would be interesting to compare to other scenarios, I may try that later today)... Again, thanks for any hints if you have some... ;-) BYE MAD On Thu, Apr 30, 2009 at 2:50 PM, Marc-Andre Decoste <[email protected]>wrote: > 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 <[email protected]>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 <[email protected]> wrote: >> >>> On Thu, Apr 30, 2009 at 7:51 AM, Marc-Andre Decoste <[email protected]> >>> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
