Make IPC::Channel::Listener:OnMessageReceived have a return value indicating whether a message was processed or not.

TBR=brettw
Review URL: http://codereview.chromium.org/5978003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70139 0039d316-1c4b-4281-b951-d872f2087c98

This regressed when I moved CrApplication out of base.

BUG=none
TEST=none

Review URL: http://codereview.chromium.org/6065007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70102 0039d316-1c4b-4281-b951-d872f2087c98

Mac: Don't hang gpu process if a tab that shares its renderer process with other tabs and that has accelerated content and outstanding paints.

The problem was that the renderer process busy-waits on the GPU process to flush all gpu commands on close, and the GPU process waits with processing commands from the renderer until a paint ack arrives from the browser. But since the window is already closed, no paint acks are sent any more.

The fix is to let the browser tell the GPU process when a window is closed, and then let the GPU process not wait for paint acks if the corresponding window has already been closed.

Closed windows are identified by (renderer process id, render view routing id). Identifying closed windows by either surface id or gpu channel stub routing id does not work, because they are both created on the GPU side and sent to the browser asynchronously, so it's possible that a browser tab is closed before the ID arrives from the GPU process – in that case, it can't send the "window closed" message even though the GPU process is already in a state where it needs this event.

BUG=67170
TEST=
1.) Go to http://www.chromeexperiments.com/detail/body-browser/?f=webgl , click "Launch Experiment", wait until everything is loaded, close popup. %cpu of gpu process and renderer process should go to 0
2.) Go to http://www.chromeexperiments.com/detail/body-browser/?f=webgl , click "Launch Experiment", wait until the bar on the left is loaded but the body isn't yet, close popup. %cpu of gpu process and renderer process should go to 0, but it might take a few seconds until the %cpu in the renderer go down (the site decides to parse the XHR data that gets flushed on widget close)
3.) Go to http://www.chromeexperiments.com/detail/nine-point-five/?f=webgl , click "Launch Experiment", wait until everything is loaded, close popup. %cpu of gpu process and renderer process should go to 0
4.) Go to http://www.chromeexperiments.com/detail/nine-point-five/?f=webgl , click "Launch Experiment", close popup immediately after the background color changed to light grey. %cpu of gpu process and renderer process should go to 0
5.) Go to http://www.chromeexperiments.com/detail/nine-point-five/?f=webgl , click "Launch Experiment", close popup immediately. %cpu of gpu process and renderer process should go to 0

Review URL: http://codereview.chromium.org/6076005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70000 0039d316-1c4b-4281-b951-d872f2087c98

BUG=49579
TEST=about:gpu page shows correct vendor-id and device-id in linux

Review URL: http://codereview.chromium.org/5861007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69836 0039d316-1c4b-4281-b951-d872f2087c98

Blacklist bad GPU drivers: currenly we disable all gpu related features if a (os, device, driver) configuration is on the blacklist.

BUG=58182
TEST=unittest

Review URL: http://codereview.chromium.org/5612002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68948 0039d316-1c4b-4281-b951-d872f2087c98

This hides some of the internals of the posix channels from users, and gets rid
of several #ifdef POSIX blocks. Generally simplifies usage of channels xplatform.

BUG=none
TEST=build

Review URL: http://codereview.chromium.org/5598010

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68621 0039d316-1c4b-4281-b951-d872f2087c98

This is a small step towards making all singleton classes use the Singleton<T> pattern within their code and not expect the callers to know about it.

This CL includes all files except those under chrome/browser, chrome/net, chrome/service and third_party/WebKit (these will be done in future CLs).

Suggested files to focus for reviewers:
- joi@ for files under src/ceee
- tommi@ for files under src/chrome_frame
- maruel@ for the rest of the files.

BUG=65298
TEST=all existing tests should continue to pass.

Review URL: http://codereview.chromium.org/5581008

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68577 0039d316-1c4b-4281-b951-d872f2087c98

I coulndn't find good enough heuristics for automatically aborting the GPU process on Windows. With this change we still have the browser's watchdog, which prompts the user if they want to kill the process if it times out.

The GPU watchdog timer seems to be working okay on Mac and Linux so I have left it enabled. For the same reason, I took out the field trial. Previously, only 15% of users were in the field trial. Now they all are.

TEST=about:gpuhang, try
BUG=65229,58396,64655

Review URL: http://codereview.chromium.org/5537006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68545 0039d316-1c4b-4281-b951-d872f2087c98

because if the context is lost those variables will
be uninitialized.

TEST=ran chrome, conformance tests, unit tests and hand edited gles2_demo to test
BUG=none

Review URL: http://codereview.chromium.org/5254006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68480 0039d316-1c4b-4281-b951-d872f2087c98

If compositor window already exists, then simply return it rather than complaining. May affect how bug 65194 manifests.

BUG=65194
TEST=Verify against WebGL demos, poster circle content with tab opening and closing, as well as killing of GPU process.

Review URL: http://codereview.chromium.org/5528007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68362 0039d316-1c4b-4281-b951-d872f2087c98

Also fix up some style issues.

CID=13912,13971,13977
BUG=none
TEST=none

Review URL: http://codereview.chromium.org/5618002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68313 0039d316-1c4b-4281-b951-d872f2087c98

This property was used by the GPU process to determine whether a particular renderer process had the right to render to a window. It turns out that this is no longer needed because now the browser tells the GPU process which child compositor window to render to and the GPU process trusts the browser process.

Also uncovered and fixed a bug in gpu_channel_host.cc where the renderer would hang if the GPU process failed to return a command buffer.

TEST=try
BUG=64834

Review URL: http://codereview.chromium.org/5607001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68096 0039d316-1c4b-4281-b951-d872f2087c98

Add a base class for objects that want to filter messages on the IO thread.  I'll switch the filters to it in future separate changes.

I've also taken out the special case for an initial filter from the IPC classes.  The reason it existed was that there was a race condition of some messages not being filtered if a filter is added after construction but before launching the peer process.  Taking it out allows us to add more than one filter and makes things a little cleaner.
Review URL: http://codereview.chromium.org/5513001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68043 0039d316-1c4b-4281-b951-d872f2087c98

The sandbox config allows everything for now; I will put in restrictions in a follow-up CL (which should be small).

This CL should have no visible effect (other than changing a few LOG(WARNING) to LOG(ERROR)).

BUG=48607
TEST=GPU process still works

Review URL: http://codereview.chromium.org/5491001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67939 0039d316-1c4b-4281-b951-d872f2087c98

BUG=64850

TEST=Verify that associated crash goes away in Canary

Review URL: http://codereview.chromium.org/5490001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67917 0039d316-1c4b-4281-b951-d872f2087c98

Switched GPU watchdog timeout to be based on main thread's user + kernel time rather than wall clock time on Windows.

Only on Windows because it is the only platform 58396 appears to be happening on. My latest hairbrained theory is that it is timing out and aborting while Windows boxes are resuming from hypernation. In that case wall clock time might incorporate a lot of I/O time for paging in data from swapfile. This is an attempt to hide that I/O time, counting only active CPU time.

It catches hangs like this:

for (;;) {
}

and this:

for (;;) {
  Sleep(0);
}

but not this:

for (;;) {
  Sleep(1000);
}

because that just makes the thread largely idle. It also does not catch deadlocks.

Also fixed null dereference in GPU watchdog termination code.

BUG=64648, 58396
TEST=test GPU watchdog locally, try

Review URL: http://codereview.chromium.org/5301007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67891 0039d316-1c4b-4281-b951-d872f2087c98

When a tab is closed, it takes a while before the GPU stops drawing into the window. Destroying the window before the GPU has flushed its drawing pipeline causes unsightly X11 errors. The custom widget class that we use for drawing
tab contents has a lock that is set when the GPU process is drawing to that widget. We use this lock to determine who should delete the associated window:
- if the lock is clear at the time of widget destruction, the widget destroys the window
- if the lock is set, the GPU process signals to the browser to destroy the widget (it has to be done in the browser process b/c the X window is wrapped in a GdkWindow that resides in the browser address space)

Most the management is done in GtkNativeViewManager. I've added another map from XID to GtkWidget to facilitate this management.

BUG=55158

TEST=Open two windows with http://webkit.org/blog-files/3d-transforms/poster-circle.html Close one of them. There should be no X11 errors generated.

Review URL: http://codereview.chromium.org/5275009

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67719 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none
TEST=none
Review URL: http://codereview.chromium.org/5139006

TBR=thestig@chromium.org
Review URL: http://codereview.chromium.org/5270010

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67674 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none
TEST=none
Review URL: http://codereview.chromium.org/5139006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67662 0039d316-1c4b-4281-b951-d872f2087c98

CompositorHostWindow and CompositorWindow inside the RenderWidgetHostView. The host-side
HWND is used to position the compositor output relative to plugins; the GPU process creates the
compositor window as a child of the CompositorHostWindow.

Once we land webkit bugfix 49396, ANGLE issue 3038042, Chromium issue 4671003, this will fix
bugs 54301 and 61516 for windows.


BUG=none
TEST=none

Review URL: http://codereview.chromium.org/4815001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67495 0039d316-1c4b-4281-b951-d872f2087c98

between GPU process and browser process. Thanks to Al Patrick for the
renderer<->GPU flow control mechanism.

This CL prevents the renderer from issuing more OpenGL work than the
GPU process can execute, and, on the Mac, prevents the combination of
the renderer and GPU processes from transmitting more frames via
IOSurfaces from the GPU to the browser process than can be handled by
the GPU.

This fix causes the renderer to block inside ggl::SwapBuffers() when
it gets too far ahead. Different strategies can be considered going
forward, including measuring frame rates in the GPU and renderer
processes and trying to match them via techniques such as delaying the
execution of some timers. However, despite the general undesirability
of blocking the render thread, this fix results in a significant
performance improvement.

With this fix integrated, a fill-limited test case from Chris Rogers
displays at 60 FPS instead of 15 FPS on a Mac Pro. Gregg Tavares'
aquarium from webglsamples.googlecode.com displays at 30 FPS instead
of 4 or 5 FPS on a MacBook Pro. The frame rates measured at the
JavaScript level now match the actual frame rate of the browser, where
previously they were much higher since they were issuing more work
than the browser could render.

A few other minor OpenGL bugs potentially impacting the correctness of
the Mac compositor are being fixed as well in this CL.

Verified that WebGL, CSS 3D and YouTube (Core Animation plugin)
content all work.

BUG=63539
TEST=none

Review URL: http://codereview.chromium.org/5317007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67470 0039d316-1c4b-4281-b951-d872f2087c98

This patch makes synchronous calls from the GPU to the Browser process to resize windows. It must be synchronous because we must be sure when the resize happens, it must be initiated by the GPU because we have to time the resize with GL drawing, and the resize must be done by the Browser because of how GDK/GTK is structured. Specifically, when a window that a GL context is associated with is resized, the back buffer gets blanked. So it is important that we synchronize the resize with the drawing to the back buffer. On Linux, the X window that we are drawing to is wrapped in a GdkWindow inside the Browser process. GDK/GTK assumes that all changes to the window happen via GDK calls. In particular, the size of the window is cached inside the GdkWindow object so that it does not have to make a call to the X server in order to get window geometry. Unfortunately, this necessitates resizing the window inside of the Browser process.

For more discussion of this approach and (some unsuccessfully attempted) alternatives see https://docs.google.com/a/google.com/document/d/1ZNouL-X_Ml1x8sqy-sofz63pDAeo36VWi_yQihaE2YI/edit?hl=en

This patch set uncovered another bug:
- open in two separate windows http://webkit.org/blog/386/3d-transforms/ and http://webkit.org/blog-files/3d-transforms/poster-circle.html
- resize the former until it is smallish
- watch the root layer of the former show up as the root layer of the later.

To my knowledge, this is first trigger of this bug. If and when this patch is accepted, I will file the bug.

BUG=http://code.google.com/p/chromium/issues/detail?id=54430

TEST=Go to http://peter.sh/2010/06/chromium-now-features-gpu-acceleration-and-css-3d-transforms/ . Rotate Z with the slider to trigger the compositor. Resize the window. The resize may be janky (we're uploading large textures), but it should display properly.

Contributed by backer@chromium.org

Review URL: http://codereview.chromium.org/5105006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67416 0039d316-1c4b-4281-b951-d872f2087c98

Revert 67293 BrowserTestCanLaunchWithOSMesa was consistently failing - Initialize destinations variables before calling GL functions
because if the context is lost those variables will
be uninitialized.

TEST=ran chrome, conformance tests, unit tests and hand edited gles2_demo to test
BUG=none

Review URL: http://codereview.chromium.org/5305005

TBR=gman@chromium.org
Review URL: http://codereview.chromium.org/5383001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67328 0039d316-1c4b-4281-b951-d872f2087c98

because if the context is lost those variables will
be uninitialized.

TEST=ran chrome, conformance tests, unit tests and hand edited gles2_demo to test
BUG=none

Review URL: http://codereview.chromium.org/5305005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67293 0039d316-1c4b-4281-b951-d872f2087c98

It used to only acknowledge upon receiving a particular kind of Task from the watchdog, which could potentially be delayed by other Tasks.

TEST=WebGL locally, check recovery from about:gpuhang locally, try
BUG=none

Review URL: http://codereview.chromium.org/5278006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67184 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none
TEST=none
Review URL: http://codereview.chromium.org/5066002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66355 0039d316-1c4b-4281-b951-d872f2087c98

Collecting GPU info was taking enough time to make the GPU watchdog abort the GPU process.

Moved GTK initialization into GpuProcess (but still before gfx::GLContext::InitializeOneOff).

TEST=try
BUG=none

Review URL: http://codereview.chromium.org/5017004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66333 0039d316-1c4b-4281-b951-d872f2087c98

The Gpu channel name is derived from the GPU pid and the renderer id. When a render view crashes and is reloaded, a channel with the same pid and renderer id will be created in the gpu process, which causes this check to fail:

[36009:263:2890157912966265:FATAL:/Volumes/Data/thakis/chrome/src/ipc/ipc_channel_posix.cc(108)] Check failed: i == map_.end(). Creating second IPC server (fd 15) for '36009.r2' while first (fd 14) still exists
Backtrace:
	0   Chromium Framework                  0x00cafe62 base::debug::StackTrace::StackTrace() + 32
	1   Chromium Framework                  0x00cc6b20 logging::LogMessage::~LogMessage() + 64
	2   Chromium Framework                  0x017f6834 IPC::(anonymous namespace)::PipeMap::Insert(std::string const&, int) + 644
	3   Chromium Framework                  0x017f6887 IPC::AddChannelSocket(std::string const&, int) + 25
	4   Chromium Framework                  0x00b3efcb GpuChannel::Init() + 103
	5   Chromium Framework                  0x00b470ff GpuThread::OnEstablishChannel(int) + 407
	6   Chromium Framework                  0x00b4778d void DispatchToMethod<GpuThread, void (GpuThread::*)(int), int>(GpuThread*, void (GpuThread::*)(int), Tuple1<int> const&) + 65
	7   Chromium Framework                  0x00b48c52 bool IPC::MessageWithTuple<Tuple1<int> >::Dispatch<GpuThread, void (GpuThread::*)(int)>(IPC::Message const*, GpuThread*, void (GpuThread::*)(int)) + 71
	8   Chromium Framework                  0x00b472f8 GpuThread::OnControlMessageReceived(IPC::Message const&) + 146
	9   Chromium Framework                  0x001696f6 ChildThread::OnMessageReceived(IPC::Message const&) + 452
	10  Chromium Framework                  0x017f9bcc IPC::ChannelProxy::Context::OnDispatchMessage(IPC::Message const&) + 144
	11  Chromium Framework                  0x017fab64 void DispatchToMethod<IPC::ChannelProxy::Context, void (IPC::ChannelProxy::Context::*)(IPC::Message const&), IPC::Message>(IPC::ChannelProxy::Context*, void (IPC::ChannelProxy::Context::*)(IPC::Message const&), Tuple1<IPC::Message> const&) + 63
	12  Chromium Framework                  0x017fab9f RunnableMethod<IPC::ChannelProxy::Context, void (IPC::ChannelProxy::Context::*)(IPC::Message const&), Tuple1<IPC::Message> >::Run() + 57
	13  Chromium Framework                  0x00ccdc39 MessageLoop::RunTask(Task*) + 303
	14  Chromium Framework                  0x00ccdcf1 MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) + 53
	15  Chromium Framework                  0x00ccdfcf MessageLoop::DoWork() + 253
	16  Chromium Framework                  0x00d42024 base::MessagePumpCFRunLoopBase::RunWork() + 74
	17  Chromium Framework                  0x00d42069 base::MessagePumpCFRunLoopBase::RunWorkSource(void*) + 23
	18  CoreFoundation                      0x96f260fb __CFRunLoopDoSources0 + 1563
	19  CoreFoundation                      0x96f23bbf __CFRunLoopRun + 1071
	20  CoreFoundation                      0x96f23094 CFRunLoopRunSpecific + 452
	21  CoreFoundation                      0x96f22ec1 CFRunLoopRunInMode + 97
	22  HIToolbox                           0x976c2f9c RunCurrentEventLoopInMode + 392
	23  HIToolbox                           0x976c2d51 ReceiveNextEventCommon + 354
	24  HIToolbox                           0x976c2bd6 BlockUntilNextEventMatchingListInMode + 81
	25  AppKit                              0x920b5a89 _DPSNextEvent + 847
	26  AppKit                              0x920b52ca -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
	27  AppKit                              0x9207755b -[NSApplication run] + 821
	28  Chromium Framework                  0x00d41b66 base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) + 130
	29  Chromium Framework                  0x00d42155 base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) + 175
	30  Chromium Framework                  0x00cce7db MessageLoop::RunInternal() + 209
	31  Chromium Framework                  0x00cce7f5 MessageLoop::RunHandler() + 17
	32  Chromium Framework                  0x00cce859 MessageLoop::Run() + 35
	33  Chromium Framework                  0x00b466e6 GpuMain(MainFunctionParams const&) + 1123
	34  Chromium Framework                  0x00008d67 ChromeMain + 4921
	35  Chromium Helper                     0x00001f52 main + 24
	36  Chromium Helper                     0x00001f0e start + 54
	37  ???                                 0x00000003 0x0 + 3

The fix is to unregister the channel-name mapping when the GPU channel goes away.

BUG=55641
TEST=Go to a gpu-accelerated page. Enter about:crash in omnibox. Reload page. No CHECK should be printed, and the page should reload fine.

Review URL: http://codereview.chromium.org/4979005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66304 0039d316-1c4b-4281-b951-d872f2087c98

Collecting this can take a couple of seconds. I put the code onto a worker thread. The about:gpuinfo handler polls for it until it is available, initially displaying only the subset of informtation that can be retreived quickly.

This makes the startup time for accelerated compositing, WebGL, etc significantly lower on Windows. None of the other platforms have this issue.

TEST=go to about:gpuinfo, try
BUG=59711

Review URL: http://codereview.chromium.org/4860001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66184 0039d316-1c4b-4281-b951-d872f2087c98

TEST=try
BUG=none

Review URL: http://codereview.chromium.org/4655003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65610 0039d316-1c4b-4281-b951-d872f2087c98

GPU process to crash on startup.

BUG=62581
TEST=none (ran CSS 3D and WebGL content)

Review URL: http://codereview.chromium.org/4641003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65576 0039d316-1c4b-4281-b951-d872f2087c98

I disabled the GPU watchdog in three new cases:
- If the OSMesa software renderer is in use. This will disable it on bots.
- When running on valgrind, whether on a bot or locally.
- In debug builds

I added a GPU process initialization time to the GPU info.

I moved the GPU initialization code outside the watchdog protection because it
can take a long time and trigger the watchdog.

I increased the timeout. I set up a field trial with different timeouts to see
the rate of failure for each period.

Original CL description:

I added a watchdog thread that intermitently checks the main thread can respond
to tasks posted on its message queue.

I fixed some bugs that prevented GGL from failing when the GPU channel was
lost.

Added a command line swith to disable the watchdog thread for debugging
purposes.

TEST=try, local testing of all features
BUG=none


git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65461 0039d316-1c4b-4281-b951-d872f2087c98

This required that GPU initialization not fail if GPU info cannot be collected.

The accelerated compositor still needs some work but this will let us run some WebGL browser and ui smoke tests.

Also added --disable-accelerated-compositing for browser and ui tests so they will not attempt to use it.

TEST=try, run ui test locally
BUG=61037, 58343

Review URL: http://codereview.chromium.org/4716002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65447 0039d316-1c4b-4281-b951-d872f2087c98

--enable-video-layering flags. With the introduction of accelerated
compositing to Chromium this code is now obsolete, and it is causing
problems and bug reports when users experiment with these flags.

Tested on Linux in the following configurations:
 - Compositor on, CSS 3D content
 - Compositor on, HTML5 video content
 - Compositor off, HTML5 video content

Also ran patch successfully through the try bots.

BUG=54932
TEST=none

Review URL: http://codereview.chromium.org/4399003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65383 0039d316-1c4b-4281-b951-d872f2087c98

I wanted to do the same thing in a third place.

TEST=compiles

Review URL: http://codereview.chromium.org/4508004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65263 0039d316-1c4b-4281-b951-d872f2087c98

Build break.

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65247 0039d316-1c4b-4281-b951-d872f2087c98

I wanted to do the same thing in a third place.

TEST=compiles

Review URL: http://codereview.chromium.org/4508004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65246 0039d316-1c4b-4281-b951-d872f2087c98

- Move dependencies closer to where they're used.
- Remove redundant comments.

Review URL: http://codereview.chromium.org/4511001

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65134 0039d316-1c4b-4281-b951-d872f2087c98

(Note: This was a TODO for hclam).

BUG=None
TEST=trybots

Review URL: http://codereview.chromium.org/4113006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64526 0039d316-1c4b-4281-b951-d872f2087c98

Currently, this is only used to DCHECK a currently implicit invariant, but I want to use this to let every surface container only remember its last painted-to surface, and not its last created surface.

No behavior change.

BUG=53165
TEST=none

Review URL: http://codereview.chromium.org/4142004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64317 0039d316-1c4b-4281-b951-d872f2087c98