Firefox/Thunderbird 7 or later renders pretty slow on xBGR display and no RENDER extension. The slow path is 0. 0. gfxContext::Paint(double) 0. 0. _moz_cairo_paint_with_alpha 0. 0. _cairo_gstate_paint 0. 0. _cairo_surface_paint 0. 0. _cairo_surface_fallback_paint 0. 0. _clip_and_composite_region 0. 0. _cairo_surface_composite 0. 0. _cairo_xlib_surface_composite 0. 0. _cairo_xlib_surface_upload 0. 0. _draw_image_surface 0.670 0.670 _XPutPixel32 and 0. 0. gfxContext::Fill() 0. 0. _moz_cairo_fill_preserve 0. 0. _cairo_gstate_fill 0. 0. _cairo_surface_fill 0. 0. _cairo_surface_fallback_fill 0. 0. _clip_and_composite_trapezoids 0. 0. _clip_and_composite_region 0. 0. _cairo_surface_composite 0. 0. _cairo_xlib_surface_composite 0. 0. _cairo_xlib_surface_upload 0. 0. _draw_image_surface 0.680 0.680 _XPutPixel32 _cairo_xlib_surface_upload is new in cairo 1.10. It seems it caused the regression.

Do not do upload if RGB masks don't match. It will avoid falling into slow XPutPixel32 path. The patch improves gfxContext::Fill() performance ~15 times with xBGR visual and no RENDER extension. (although it is still ~ 10 times slower than the RENDER path.)

Comment on attachment 586909 [details] [diff] [review] patch Let's also accept a review by Jeff here. He can push it upstream if it works for him.

(In reply to Joe Drew (not getting mail) from comment #2) > Comment on attachment 586909 [details] [diff] [review] > patch > > Let's also accept a review by Jeff here. He can push it upstream if it works > for him. Looks like this was missed - is it still valid?

This is still being used for FF build on Solaris. Ginn, can you please comment whether this is still valid?