Allocate SharedBitmaps on FILE_USER_BLOCKING thread.

Allocate SharedBitmaps on FILE_USER_BLOCKING thread.

Allocating these can be expensive (especially on OS X) so it's best not to block the IO thread while doing that.

BUG=

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=276358

[piman, 2014-06-09 18:35:05]

https://codereview.chromium.org/317973004/diff/20001/content/browser/renderer...
File content/browser/renderer_host/render_message_filter.cc (right):

https://codereview.chromium.org/317973004/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_message_filter.cc:331: // This function
should be called on the IO thread.
I think this invariant is violated now, because we send a reference to the
FILE_USER_BLOCKING thread (which, on top of this, outlives IO).

[jbauman, 2014-06-09 19:22:26]

https://codereview.chromium.org/317973004/diff/20001/content/browser/renderer...
File content/browser/renderer_host/render_message_filter.cc (right):

https://codereview.chromium.org/317973004/diff/20001/content/browser/renderer...
content/browser/renderer_host/render_message_filter.cc:331: // This function
should be called on the IO thread.
On 2014/06/09 18:35:05, piman wrote:
> I think this invariant is violated now, because we send a reference to the
> FILE_USER_BLOCKING thread (which, on top of this, outlives IO).

We already do this in RenderMessageFilter::OnLoadFont. This should be safe
because when the refcount reaches 0 BrowserMessageFilterTraits calls
RenderMessageFilter::OnDestruct, which posts a task to the IO thread to destroy
it.

Of course it could leak if FILE_USER_BLOCKING is still holding a reference when
the IO thread is destroyed, but I'm not sure we care about that.

[piman, 2014-06-10 00:41:04]

I see, ok.
I'm not super excited about flaky leaks (FILE_USER_BLOCKING outlives the IO
thread), but I suppose it's already present so...

LGTM

[jbauman, 2014-06-10 16:59:03]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2014-06-10 17:02:24]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jbauman@chromium.org/317973004/20001

[commit-bot: I haz the power, 2014-06-11 11:59:36]

Change committed as 276358