Improve performance of dragged tab renderering....

Improve performance of dragged tab renderering.

Do as much as possible server side.

I suspect the main factors that made our previous implementation slow were blitting from client to server, several unnecessary copies of the entire image, and doing an in-memory rgba->bgra swap.

Now, even in debug mode with a 30" chrome window, the performance is very fast.

BUG=16257, 15869
TEST=drag a tab out of the tabstrip, with and without compositing


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=20333

[agl, 2009-07-09 21:53:32]

I don't know that much about Cairo's interactions with Xlib but, if it works,
LGTM.

[Evan Martin, 2009-07-09 22:15:13]

It's not clear to me cairo is doing anything magical here -- the chrome skbitmap
scaler is slower than a normal scale because we do better scaling.  Have you
verified the perf win isn't due to that?

[James Hawkins, 2009-07-09 22:16:12]

http://codereview.chromium.org/155321/diff/11/1014
File chrome/browser/gtk/tabs/dragged_tab_gtk.cc (right):

http://codereview.chromium.org/155321/diff/11/1014#newcode275
Line 275: gfx::Rect(1, tab_height, widget->allocation.width - 2,
Please use the previous logic for image_(x,y,w,h) starting on line 250 of the
previous code.  kDragFrameBorderSize is 2, so I don't think the x coord of this
is right.  Also, the width should be kTwiceDragFrameBorderSize because we must
take into account the border on both sides of the contents.  Similar problem
with the height.

http://codereview.chromium.org/155321/diff/11/1014#newcode283
Line 283: cairo_set_line_width(cr, 1.0);
The border is 2 pixels wide: kDragFrameBorderSize.

http://codereview.chromium.org/155321/diff/11/1014#newcode289
Line 289: cairo_move_to(cr, 0, tab_height - 1);
As above, kDragFrameBorderSize.

[Evan Stade, 2009-07-09 22:54:29]

updated to use kDragFrameBorderSize and generalized logic to work for any border
size. Changed kDragFrameBorderSize to 1 because 2 is the pre-shrinkage size, and
1 is the goal post-shrinkage size.

[James Hawkins, 2009-07-09 22:57:57]

On 2009/07/09 22:54:29, Evan Stade wrote:
> updated to use kDragFrameBorderSize and generalized logic to work for any
border
> size. Changed kDragFrameBorderSize to 1 because 2 is the pre-shrinkage size,
and
> 1 is the goal post-shrinkage size.

LGTM

[Evan Stade, 2009-07-09 22:59:15]

thx for review

[brettw, 2009-07-09 23:00:04]

On Thu, Jul 9, 2009 at 3:15 PM, <evan@chromium.org> wrote:
> It's not clear to me cairo is doing anything magical here -- the chrome
> skbitmap scaler is slower than a normal scale because we do better
> scaling. =A0Have you verified the perf win isn't due to that?
>
> http://codereview.chromium.org/155321

I agree with Evan. You could have taken out all the crazy mipmapping
code and all the extra fills, and Skia would have been just as fast.

I don't object to the new code, however.

Brett

[Evan Stade, 2009-07-09 23:28:04]

On 2009/07/09 22:15:13, Evan Martin wrote:
> It's not clear to me cairo is doing anything magical here -- the chrome
skbitmap
> scaler is slower than a normal scale because we do better scaling.  Have you
> verified the perf win isn't due to that?

sorry, I missed this comment. No, I didn't verify that. Testing now.

[Evan Martin, 2009-07-09 23:35:46]

On 2009/07/09 23:28:04, Evan Stade wrote:
> On 2009/07/09 22:15:13, Evan Martin wrote:
> > It's not clear to me cairo is doing anything magical here -- the chrome
> skbitmap
> > scaler is slower than a normal scale because we do better scaling.  Have you
> > verified the perf win isn't due to that?
> 
> sorry, I missed this comment. No, I didn't verify that. Testing now.

One thing to try is to remove the scaling, and instead just take the upper-left
quadrant, in both the skia and cairo paths.

I think we *can* do a server-side scale, which has the advantage of using the
video driver, but you'll probably need to call into xrender directly for that. 
And I also think the server-side image scalers produce terrible graphics
dependent on hardware, so maybe it's a bad idea.  :(

[Evan Stade, 2009-07-09 23:44:53]

OK, did testing where I just removed the scale on the old code. This is all
anecdotal, but the results are clear. The old code with the scale removed in
Release is noticeably slower than the new code with the scale in place in Debug.