384266 - Painting native-themed form controls to canvas is very slow

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Trying to paint the following document:

  data:text/html,<input type="button"><select><option>aaa</select>

To a canvas over here takes 3-4 seconds of 100% CPU.  Hovering over a non-foreground bugzilla tab (with the bug page scrolled to the top) in Seamonkey (which should paint it into a canvas and show that as the preview image) hangs my X for about 30-40 seconds and never shows the preview (because I think the timer for it runs out before we're done painting).

I get the same situation with http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB33081760H when it's scrolled to the top.  If I scroll down until I no longer see the form elements, things suddenly work.

The CPU usage is split between X and mozilla (about 50-50, for the most part), and we allocate and deallocate large chunks of memory over and over in mozilla during the whole time (over here, it oscillates between about 200MB and 500MB RAM usage).

Comment 1

[Michael Ventnor]

The stack goes into thebes, which I know nothing about... 
Does this happen with XUL as well?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You might want to check the surface sizes being allocated in cairo-xlib-utils.c

Comment 3

[Boris Zbarsky [:bzbarsky]]

I don't know whether it happens with XUL; do you have an easy-to-use testcase with lots of XUL native-themed stuff in it that calls drawWindow?

Will check on surface sizes.

Comment 4

[Boris Zbarsky [:bzbarsky]]

roc, good call!  Some typical surface sizes being created by _create_temp_xlib_surface:

11460x1380 -- combobox background
14100x1380 -- combobox background
6960x1380 -- combobox background
19680x1320 -- text control background
19680x1320 -- text control background
19680x1320 -- text control background

Looking at nsNativeThemeGTK::DrawWidgetBackground, we seem to be passing rects in twips down to the gfxXlibNativeRenderer code....

I wonder why this is not a problem when painting on screen, at least as far as I can tell.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I guess in the screen case we go through draw_with_xlib_direct, eh?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think that, or maybe that in DrawWidgetBackground, when snapXY is true we convert to pixels, otherwise we don't...

So NSAppUnitsToIntPixels should be added to the !snapXY path. I'd review that patch :-)

Comment 7

[Boris Zbarsky [:bzbarsky]]

Uh... I'm not sure I follow.  The snapXY path rounds the width and height to an integer number of pixels (twice, in fact, which seems silly).  Using NSAppUnitsToIntPixels on the !snapXY path woudl make it do exactly the same rounding.  Why have two paths, then?

Note that in this case snapXY is false because of:

(gdb) p current
$3 = {xx = 0.23166023194789886, yx = 0, xy = 0, yy = 0.23209549486637115, 
  x0 = 33.092664133757353, y0 = 15.585212480276825}

presumably because the canvas size is smaller than the window size of the window we're painting into it....

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed patch

This seems to fix things over here.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Rounding up

Comment 10

[Boris Zbarsky [:bzbarsky]]

Checked in.

Comment 11

[Boris Zbarsky [:bzbarsky]]

I think we should be able to test these sort of things...