PolyRectFill preformance

[Simon Thum]

Hi Ross,

is there speciality to those pages? E.g. I had similar dropouts with 
pages that had dotted lines (even in very small amounts). FF3 should fix 
that, though not checked yet.

Ross Vandegrift wrote:
> On Sun, Mar 16, 2008 at 03:40:41PM -0400, Ross Vandegrift wrote:
>> According to my profiling, these web pages are causing lots of calls to
>> *PolyRectFill.  In both EXA and XAA versions, it looks like the
>> non-accel fallbacks end up in fbBlt.  These calls are from Mozilla's
>> libgfx_gtk.
>>
>> I'm hoping to find a simpler test case with x11perf.  I'm currently trying
>> to go through x11perf tests to see if I can find a test that'll hit
>> this, but so far no dice (the vast majority of CPU time is being spent
>> in nv_drv.so, which makes me think I haven't found the software
>> fallback yet).
>>
>> Any tips on tracking this down?
> 
> Following up to myself...
> 
> My x11perf and render_bench tests finished.  None of the rect tests
> and none of the render_bench tests hit this code path.
> 
> Briefly, here's the data I have gathered from oprofiling my box while
> testing with mozilla:
> 
> 284083 samples from libfb.so make up 53% of measured events
> 278681 of those are from fbBlt
> Nearly all of those have this callstack:
> 
> 	fbBlt
> 	fbOddTile
> 	fbTile
> 	fbFill
> 	fbPolyFillRect
> 
> oprofile's callgraph doesn't include who is calling fbPolyFillRect,
> but I see 302393 cases of exaPolyFillRect -> ExaCheckPolyFillRect ->
> fbPolyFillRect, so that path seems like the most likely candidate.
> 
> Beyond this, I can't seem to coax any data out of oprofile on what
> mozilla is doing to cause this.
>