summaryrefslogtreecommitdiffstats
path: root/chrome/browser/gpu_process_host_ui_shim.h
Commit message (Collapse)AuthorAgeFilesLines
* Refactor GPUProcessHost to eliminate redundancy.backer@chromium.org2011-01-211-1/+23
| | | | | | | | | | | There was a lot of thread hopping from IO to UI back to IO to answer requests. This is was GpuProcessHostUIShim is for. Refactored to take advantage of it. BUG=none TEST=by hand and trybots Review URL: http://codereview.chromium.org/6374007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@72161 0039d316-1c4b-4281-b951-d872f2087c98
* Move non_thread_safe from base to base/threading and into the base namespace.brettw@chromium.org2011-01-011-2/+2
| | | | | | | | TEST=it compiles BUG=none Review URL: http://codereview.chromium.org/6005010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70351 0039d316-1c4b-4281-b951-d872f2087c98
* Make IPC::Channel::Listener:OnMessageReceived have a return value indicating ↵jam@chromium.org2010-12-241-2/+2
| | | | | | | | | 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
* Wait for the GPU info to be collected.kkania@chromium.org2010-12-141-0/+13
| | | | | | | | BUG=59131 TEST=none Review URL: http://codereview.chromium.org/5698009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69151 0039d316-1c4b-4281-b951-d872f2087c98
* Rename all methods accessing Singleton<T> as GetInstance().satish@chromium.org2010-12-131-1/+1
| | | | | | | | | | | | | This is in preparation to a subsequent CL where Singleton<T> will restrict access to only the type being made singleton. I also moved pepper::ResourceTracker to a lazy instance since there were too many places in code where this class was being accessed from and this was a smaller change than renaming methods in that case. BUG=65298 TEST=all existing tests should pass. Review URL: http://codereview.chromium.org/5685007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68982 0039d316-1c4b-4281-b951-d872f2087c98
* When accelerated compositing is enabled, we create a plugin-like pair of ↵nduca@chromium.org2010-11-271-1/+1
| | | | | | | | | | | | | | | | | | | windows, 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
* Cleaned up thread safety for GpuProcessHost and GpuProcessHostUIShim.apatrick@chromium.org2010-11-171-1/+14
| | | | | | | | | | | | | | | | | Guarded static members with an assertion that they are invoked on the right thread. Guarded non-static members with an assertion that NonThreadSafe::CalledOnValidThread() is true. GpuProcessHost automatically routes unhandled control messages to the UI shim. Moved gpu_info to the UI shim, which is the thread it is accessed on. TEST=webgl, CSS 3D locally, try BUG=none Review URL: http://codereview.chromium.org/5130001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66482 0039d316-1c4b-4281-b951-d872f2087c98
* - Relanding 61718.apatrick@chromium.org2010-11-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Deleted code associated with --enable-gpu-rendering andkbr@chromium.org2010-11-081-5/+0
| | | | | | | | | | | | | | | | | | | | --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
* Revert 63388 - ↵stoyan@chromium.org2010-10-211-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | http://build.chromium.org/buildbot/waterfall/builders/Mac10.6%20Tests%20(dbg)(2)/builds/10949 - Relanding 61718. 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. I made ui_tests always run with OSMesa, for consistent operation on bots and when run locally. 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 preventede 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 Review URL: http://codereview.chromium.org/3794011 TBR=apatrick@chromium.org Review URL: http://codereview.chromium.org/3979004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63396 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding 61718.apatrick@chromium.org2010-10-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. I made ui_tests always run with OSMesa, for consistent operation on bots and when run locally. 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 preventede 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 Review URL: http://codereview.chromium.org/3794011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63388 0039d316-1c4b-4281-b951-d872f2087c98
* Updating the about:gpu to start a webgl context if one does not exist so ↵rlp@chromium.org2010-09-101-0/+4
| | | | | | | | | | | | | | | | | | that some gpu_info will actually exist. It does this by refreshing the page every 5 seconds until a context does exist, if necessary. We also looked into other methods: - synchronous call to create context, but that will hang if there are issues creating a context - a call back, but that will also hang until we have a gpu context - display no data and rely on the user to refresh which is somewhat unintuitive to the user The method in this CL seemed to be the least annoying method of doing this which didn't cause the browser to hang. BUG=none TEST=visual Review URL: http://codereview.chromium.org/3348007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59141 0039d316-1c4b-4281-b951-d872f2087c98
* `#pragma once` for app, base, chrome, gfx, ipc, net, skia, viewsthakis@chromium.org2010-07-261-0/+1
| | | | | | | | | BUG=50273 TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux TBR: erg git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
* Split GpuProcessHost into GpuProcessHostUIShim, which runs on the UIkbr@google.com2010-03-301-0/+56
thread, and GpuProcessHost, which now runs on the IO thread and derives from ChildProcessHost. This split was necessary in order to service synchronous messages from the renderer process. Moved message handlers for GPU messages from renderer to browser from BrowserRenderProcessHost to ResourceMessageFilter. Stopped sending multiple ViewHostMsg_EstablishGpuChannel messages from the same renderer if the connection was already established. Resetting the channel was causing failures in Send, and every other page reload containing WebGL content to fail. This cleanup will allow further simplification in the GPU process, but this is being left for a subsequent CL. Fixed bug in sandboxing of GPU process. Fixed latent bugs in cleanup code in GpuChannel and GpuChannelHost. Fixed crashes in ChildProcessHost if resource_dispatcher_host_ was NULL. Fixed apparent latent race conditions in creation of BackingStoreProxy and VideoLayerProxy. With these changes, WebGL content is running in the sandbox on both Mac and Windows. Linux support will be added in a following CL. BUG=29120 TEST=ran WebGL demos on Mac and Windows Review URL: http://codereview.chromium.org/1546001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43029 0039d316-1c4b-4281-b951-d872f2087c98