summaryrefslogtreecommitdiffstats
path: root/chrome/browser/gpu_process_host.h
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Create a ResourceMessageFilter to filter resource related IPCs. This gets ↵jam@chromium.org2010-12-151-5/+0
| | | | | | | | rid of the awkward ResourceDispatcherHost::Receiver interface and allows a bunch of cleanup. I've also generalized the filtering done in WorkerProcessHost and moved it to ChildProcessHost (since it's now used to add the ResourceMessageFilter). Review URL: http://codereview.chromium.org/5874002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69335 0039d316-1c4b-4281-b951-d872f2087c98
* This adds some plumbing for propagating the status and error code of a ↵gspencer@chromium.org2010-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | renderer process that went away so that we can tell at the UI level what happened to the tab: did it crash, or was it killed by the OOM killer (or some other reason). This is in preparation for implementing a new UI for when a process is killed by the OOM on ChromeOS which handles it differently from a crash. Most of the changes are modifications of the argument list to include a status and error code for the exited process, but in addition the following was done: - Changed the name of DidProcessCrash to GetTerminationStatus. - Added TerminationStatus enum in process_util.h, so it can be used as the status returned by GetTerminationStatus. - Improved process_util_unittest to actually test for crashing and terminated processes on all platforms. - Added a new notification for renderers that were killed. - Added error code information to crash notification. - Added status and error code information to renderer IPC message for RenderViewGone. - Added a UMA histogram count for number of renderer kills. BUG=http://crosbug.com/8505 TEST=ran new unit test. Test passes on try servers. Review URL: http://codereview.chromium.org/5172009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69082 0039d316-1c4b-4281-b951-d872f2087c98
* Rename ResourceMessageFilter to RenderMessageFilter, since that's what it ↵jam@chromium.org2010-12-141-12/+9
| | | | | | | | actually is. I will add a ResourceMessageFilter just for resource IPCs in a future change. Review URL: http://codereview.chromium.org/5701004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69076 0039d316-1c4b-4281-b951-d872f2087c98
* Blacklist bad GPU drivers: currenly we disable all gpu related features if a ↵zmo@google.com2010-12-111-0/+5
| | | | | | | | | | | (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
* If compositor window already exists, then simply return it rather than ↵nduca@chromium.org2010-12-061-1/+1
| | | | | | | | | | | 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
* Defer window destruction until GPU finished drawing.backer@chromium.org2010-11-301-0/+1
| | | | | | | | | | | | | | | | | 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
* When accelerated compositing is enabled, we create a plugin-like pair of ↵nduca@chromium.org2010-11-271-0/+4
| | | | | | | | | | | | | | | | | | | 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
* Add flow control between renderer and GPU processes, and, on Mac OS X,kbr@google.com2010-11-261-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Resize synchronization for Linux.backer@chromium.org2010-11-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | 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
* Histograms added for GPU Process Crashed, Died, Launchedscheib@chromium.org2010-11-241-0/+1
| | | | | | | | | BUG=62865 TEST=none Review URL: http://codereview.chromium.org/5299003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67341 0039d316-1c4b-4281-b951-d872f2087c98
* Added GpuProcessHost::CanLaunchGpuProcess() and reorganized code to disble ↵alokp@chromium.org2010-11-221-0/+3
| | | | | | | | | launching of GPU process based on crash rate. BUG=61771 Review URL: http://codereview.chromium.org/5205006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67008 0039d316-1c4b-4281-b951-d872f2087c98
* Cleaned up thread safety for GpuProcessHost and GpuProcessHostUIShim.apatrick@chromium.org2010-11-171-14/+2
| | | | | | | | | | | | | | | | | 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
* Fixed a hang in the renderer process. If the renderer process requests for a ↵alokp@chromium.org2010-11-151-4/+10
| | | | | | | | | | channel synchronously and the channel could not be established, the renderer thread would keep waiting for the reply to synchronization request. BUG=61771 TEST=Manually tested pages that require hardware acceleration to make sure they still render correctly Review URL: http://codereview.chromium.org/4884002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66175 0039d316-1c4b-4281-b951-d872f2087c98
* - Relanding 61718.apatrick@chromium.org2010-11-091-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Let every "accelerated IO surface swapped" message have an identifier of the ↵thakis@chromium.org2010-10-281-1/+2
| | | | | | | | | | | | | | | surface. 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
* Revert 63388 - ↵stoyan@chromium.org2010-10-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* FBTF: Even more deinlining.erg@google.com2010-10-201-6/+7
| | | | | | | | | BUG=none TEST=compiles Review URL: http://codereview.chromium.org/3879002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63261 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 61718 - GPU process terminates on hang.mnissler@chromium.org2010-10-071-5/+2
| | | | | | | | | | | | | | | | | | 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, check WebGL works, check about:gpuhang terminates process. BUG=38739,53871 Review URL: http://codereview.chromium.org/3528012 TBR=apatrick@chromium.org Review URL: http://codereview.chromium.org/3616011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61782 0039d316-1c4b-4281-b951-d872f2087c98
* GPU process terminates on hang.apatrick@chromium.org2010-10-061-2/+5
| | | | | | | | | | | | | | | 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, check WebGL works, check about:gpuhang terminates process. BUG=38739,53871 Review URL: http://codereview.chromium.org/3528012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61718 0039d316-1c4b-4281-b951-d872f2087c98
* Create an X window overlay with static ID for GL contexts.piman@chromium.org2010-10-061-1/+1
| | | | | | | | | | | | | | | | | | This code creates an X window that overlays where tab contents are drawn. The handle associated with this window never changes (unlike the X window associated with a GTK widget that is created and destroyed whenever the widget is realized and unrealized respectively). This is helpful when creating a GL context associated with an X window. Also, having a floating overlay allows us to handle detaching GPU accelerated tabs. This code seems to have uncovered a race condition within the GPU process. When a tab that uses accelerated compositing is detached (e.g. http://webkit.org/blog/386/3d-transforms/), the tab contents often don't get displayed even though the tab is redrawn. A slight delay of about 100ms in the GPU process on the call to glXSwapBuffers (in gl_context_linux.cc) fixes this. To witness that GL can draw to the overlay after delay, try it with a tab with constant animation (e.g. http://webkit.org/blog-files/3d-transforms/poster-circle.html). I've written a bare bones test (about 150 lines of C) of the overlay technique, and it requires no such delay b/w reparenting the glXSwapBuffers. I've also confirmed that there is no synchronization issues w.r.t. the X server between my patch and GL draw commands. I propose filing a new bug for the race, if this patch gets accepted. BUG=53345,56419 TEST=Open two tabs, one with GPU rendered content (http://webkit.org/blog/386/3d-transforms/). Detach the tab with GPU rendered content. GPU process shouldn't crash. Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=61561 Review URL: http://codereview.chromium.org/3509004 Patch from Jonathan Backer <backer@google.com>. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61695 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 61561 - Create an X window overlay with static ID for GL contexts.dhollowa@chromium.org2010-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverting due to Valgrind issues on Linux tests: http://build.chromium.org/buildbot/memory/builders/Linux%20Tests%20(valgrind)(2)/builds/7671/steps/memory%20test:%20ui/logs/stdio Suppression (error hash=#000000007803F359#): { <insert_a_suppression_name_here> Memcheck:Addr4 fun:_ZN20GtkNativeViewManager9OnDestroyEP10_GtkWidget fun:_ZN62_GLOBAL__N_gfx_gtk_native_view_id_manager.cc_00000000_E72B30A69OnDestroyEP10_GtkObjectPv fun:g_cclosure_marshal_VOID__VOID fun:g_closure_invoke fun:signal_emit_unlocked_R fun:g_signal_emit_valist fun:g_signal_emit fun:gtk_object_dispose fun:gtk_widget_dispose fun:g_object_run_dispose fun:gtk_object_destroy fun:_ZN23RenderWidgetHostViewGtk7DestroyEv fun:_ZN16RenderWidgetHost7DestroyEv fun:_ZN16RenderWidgetHost8ShutdownEv fun:_ZN14RenderViewHost8ShutdownEv fun:_ZN21RenderViewHostManagerD1Ev fun:_ZN11TabContentsD0Ev fun:_ZN13TabStripModel16InternalCloseTabEP11TabContentsib fun:_ZN13TabStripModel17InternalCloseTabsERKSt6vectorIiSaIiEEj fun:_ZN13TabStripModel18CloseTabContentsAtEij fun:_ZN7Browser13CloseContentsEP11TabContents fun:_ZN11TabContents5CloseEP14RenderViewHost } No absolute smoking gun. But seems very likely. -- This code creates an X window that overlays where tab contents are drawn. The handle associated with this window never changes (unlike the X window associated with a GTK widget that is created and destroyed whenever the widget is realized and unrealized respectively). This is helpful when creating a GL context associated with an X window. Also, having a floating overlay allows us to handle detaching GPU accelerated tabs. This code seems to have uncovered a race condition within the GPU process. When a tab that uses accelerated compositing is detached (e.g. http://webkit.org/blog/386/3d-transforms/), the tab contents often don't get displayed even though the tab is redrawn. A slight delay of about 100ms in the GPU process on the call to glXSwapBuffers (in gl_context_linux.cc) fixes this. To witness that GL can draw to the overlay after delay, try it with a tab with constant animation (e.g. http://webkit.org/blog-files/3d-transforms/poster-circle.html). I've written a bare bones test (about 150 lines of C) of the overlay technique, and it requires no such delay b/w reparenting the glXSwapBuffers. I've also confirmed that there is no synchronization issues w.r.t. the X server between my patch and GL draw commands. I propose filing a new bug for the race, if this patch gets accepted. BUG=53345,56419 TEST=Open two tabs, one with GPU rendered content (http://webkit.org/blog/386/3d-transforms/). Detach the tab with GPU rendered content. GPU process shouldn't crash. Review URL: http://codereview.chromium.org/3509004 Patch from Jonathan Backer <backer@google.com>. TBR=piman@chromium.org Review URL: http://codereview.chromium.org/3548015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61589 0039d316-1c4b-4281-b951-d872f2087c98
* Create an X window overlay with static ID for GL contexts.piman@chromium.org2010-10-051-1/+1
| | | | | | | | | | | | | | | | This code creates an X window that overlays where tab contents are drawn. The handle associated with this window never changes (unlike the X window associated with a GTK widget that is created and destroyed whenever the widget is realized and unrealized respectively). This is helpful when creating a GL context associated with an X window. Also, having a floating overlay allows us to handle detaching GPU accelerated tabs. This code seems to have uncovered a race condition within the GPU process. When a tab that uses accelerated compositing is detached (e.g. http://webkit.org/blog/386/3d-transforms/), the tab contents often don't get displayed even though the tab is redrawn. A slight delay of about 100ms in the GPU process on the call to glXSwapBuffers (in gl_context_linux.cc) fixes this. To witness that GL can draw to the overlay after delay, try it with a tab with constant animation (e.g. http://webkit.org/blog-files/3d-transforms/poster-circle.html). I've written a bare bones test (about 150 lines of C) of the overlay technique, and it requires no such delay b/w reparenting the glXSwapBuffers. I've also confirmed that there is no synchronization issues w.r.t. the X server between my patch and GL draw commands. I propose filing a new bug for the race, if this patch gets accepted. BUG=53345,56419 TEST=Open two tabs, one with GPU rendered content (http://webkit.org/blog/386/3d-transforms/). Detach the tab with GPU rendered content. GPU process shouldn't crash. Review URL: http://codereview.chromium.org/3509004 Patch from Jonathan Backer <backer@google.com>. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61561 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 60421 - Revert 60373, trying to track down a perf regression (see bug ↵thakis@chromium.org2010-09-241-0/+4
| | | | | | | | | | | | | | | | | 56752)- Add about:gpuhang BUG=None TEST=None Review URL: http://codereview.chromium.org/3447023 TBR=thakis@chromium.org Review URL: http://codereview.chromium.org/3398027 TBR=thakis@chromium.org Review URL: http://codereview.chromium.org/3398028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60430 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 60373, trying to track down a perf regression (see bug 56752)- Add ↵thakis@chromium.org2010-09-241-4/+0
| | | | | | | | | | | | | | about:gpuhang BUG=None TEST=None Review URL: http://codereview.chromium.org/3447023 TBR=thakis@chromium.org Review URL: http://codereview.chromium.org/3398027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60421 0039d316-1c4b-4281-b951-d872f2087c98
* Add about:gpuhangthakis@chromium.org2010-09-231-0/+4
| | | | | | | | | BUG=None TEST=None Review URL: http://codereview.chromium.org/3447023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60373 0039d316-1c4b-4281-b951-d872f2087c98
* Add about:gpucrashthakis@chromium.org2010-09-151-0/+3
| | | | | | | | | BUG=None TEST=open a tab that uses the compositor. Open a second tab, go to about:gpucrash. Verify in the task manager that the gpu process is now gone. Review URL: http://codereview.chromium.org/3424007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59540 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/+1
| | | | | | | | | | | | | | | | | | 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
* Added GPU stat for whether a GPU can report context lost.apatrick@chromium.org2010-09-071-0/+2
| | | | | | | | | | | | | | | On Windows it checks to see if the IDirect3D9 object supports Vista and later features (meaning it won't routinely report lost contexts). On Linux and Mac we can just check if its EGL versus some other GL that doesn't report lost contexts. I routed the stats to the renderer process so webkit code can query whether lost contexts are likely. I didn't wire up breakpad yet. TEST=try BUG=52318 Review URL: http://codereview.chromium.org/3149016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58755 0039d316-1c4b-4281-b951-d872f2087c98
* Clean up unnecessary #includes of base/{scoped_ptr.h,string16.h}.viettrungluu@chromium.org2010-08-191-1/+1
| | | | | | | | | | | | Also fix a bunch of #includes. Folks, scoped_refptr<> is defined in base/ref_counted.h, not in base/scoped_ptr.h. BUG=none TEST=builds Review URL: http://codereview.chromium.org/3132024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56712 0039d316-1c4b-4281-b951-d872f2087c98
* Delete obviously unneeded forward declarations in chrome/browser/*.h.viettrungluu@chromium.org2010-08-051-1/+0
| | | | | | | | | BUG=none TEST=builds Review URL: http://codereview.chromium.org/3080031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55037 0039d316-1c4b-4281-b951-d872f2087c98
* Initial port of accelerated compositor to Mac OS X 10.6. Reusedkbr@google.com2010-08-041-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | infrastructure added for Pepper 3D and Core Animation plugins to render the compositor's output. The implementation allocates a fake "plugin window handle" on the browser side which is the "root" handle, containing the compositor's output, and which, if present, is drawn before any other accelerated plugin instances. Added messages from GPU process to browser process for handling window resizing and presentation of output. Added support to GGL for "view" contexts on Mac OS X, used only for the accelerated compositor, and requiring explicit resize notifications. The remainder of this port will go into the WebKit repository under https://bugs.webkit.org/show_bug.cgi?id=43398 after this for dependency reasons. Tested manually with CSS 3D and WebGL demos. Several stability and correctness issues remain and will be addressed in following CLs; however, the current code works for the majority of basic use cases including switching between accelerated compositing on and off, and scrolling of content. BUG=38969 TEST=none Review URL: http://codereview.chromium.org/3067026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54923 0039d316-1c4b-4281-b951-d872f2087c98
* CommandLine: add a CopySwitchesFrom() and AppendSwitchPath()evan@chromium.org2010-07-291-6/+0
| | | | | | | | | | | These are two common patterns in Chrome code: copying a subset of switches from one CommandLine to another, and appending a FilePath to a CommandLine. This sets me up to do a lot more deprecation in a follow-up change. Review URL: http://codereview.chromium.org/3012021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54218 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
* Added --use-gl command line flag to select GL implementation.apatrick@chromium.org2010-07-141-1/+0
| | | | | | | | | | | | - Options are desktop, egl and osmesa. - Also added support for bliting an OSMesa bask buffer to a GDK window. TEST=trybots, manual verification that WebGL and Pepper 3D work BUG=45898 Review URL: http://codereview.chromium.org/2825005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52388 0039d316-1c4b-4281-b951-d872f2087c98
* Collecting gpu information when the gpu process creates a channel. Adding ↵rlp@chromium.org2010-07-141-1/+9
| | | | | | | | | | | the gpu_info into the messages sent between gpu process and browser and sending over the browser. Will do something with it in the browser in another CR. BUG=38736 TEST=none Review URL: http://codereview.chromium.org/2857035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52356 0039d316-1c4b-4281-b951-d872f2087c98
* Moved common parts of ChildProcessHost into chrome/common and created a ↵sanjeevr@chromium.org2010-07-031-2/+2
| | | | | | | | | | | BrowserChildProcessHost with browser-specific implementation. This is in preparation of creating a ServiceChildProcessHost. BUG=None TEST=Test for regressions . Review URL: http://codereview.chromium.org/2885017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@51593 0039d316-1c4b-4281-b951-d872f2087c98
* linux: add accelerated compositing.piman@chromium.org2010-07-011-0/+4
| | | | | | | | | Similar to Windows, this doesn't handle exposes currently, nor WebGL. Other caveat: tearing off a tab causes trouble to the gpu process. Review URL: http://codereview.chromium.org/2886003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@51324 0039d316-1c4b-4281-b951-d872f2087c98
* Reduce header dependencies in chrome/phajdan.jr@chromium.org2010-05-111-0/+5
| | | | | | | | | TEST=if it compiles, it is perfect BUG=none Review URL: http://codereview.chromium.org/2001007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46894 0039d316-1c4b-4281-b951-d872f2087c98
* Split GpuProcessHost into GpuProcessHostUIShim, which runs on the UIkbr@google.com2010-03-301-56/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Added command buffer implementation of WebGL which runs in the sandbox.kbr@google.com2010-03-271-0/+8
| | | | | | | | | | | | | | | | | | | | | | Added synchronous initialization of the channel to the GPU process, needed to obey WebGL startup semantics. There are problems with this on the Windows platform which will be addressed via refactoring in the GpuProcessHost in a subsequent CL. Implemented offscreen rendering code path in GGL / GLES2CmdDecoder for Mac OS X. This new code path is not yet complete for all platforms and is still being stress tested. The previous in-process WebGL implementation is currently used when the sandbox is disabled; it will be removed in a subsequent CL. A one-line code change in WebKit is needed after this CL lands to enable the new code path. BUG=29120 TEST=ran WebGL demos on command buffer implementation on Mac Review URL: http://codereview.chromium.org/1328001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42879 0039d316-1c4b-4281-b951-d872f2087c98
* Calling OpenGL from the renderer processapatrick@chromium.org2010-03-251-9/+3
| | | | | | | | | | | | | | - Added ability for renderer processes to render to a real window (Windows only so far). - Added ability to create offscreen frame buffer objects that can be resized later. - OpenGL context can have a "parent" context that can access its last swapped back buffer through a texture ID. - Moved code to establish GPU channel from RenderWidget to RenderThread. - Changed way service size command buffer object lifetimes are managed. TEST=trybot and visual verification that OpenGL can clear the browser window to magenta. BUG=none Review URL: http://codereview.chromium.org/1136006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42679 0039d316-1c4b-4281-b951-d872f2087c98
* Propagate logging command line switches from browser process to GPU process.scherkus@chromium.org2010-03-081-0/+6
| | | | | | | | | BUG=33329 TEST=try out --log-level=0, you should see log messages Review URL: http://codereview.chromium.org/668195 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40947 0039d316-1c4b-4281-b951-d872f2087c98
* Added support for opening a GPU command buffer from a renderer processes ↵apatrick@chromium.org2010-03-051-1/+38
| | | | | | | | | | | | through a GPU channel. Probably only works in windows only so far. TEST=none BUG=none Review URL: http://codereview.chromium.org/657046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40783 0039d316-1c4b-4281-b951-d872f2087c98
* Create initial GPU backing store in the GPU process for X windows applications.brettw@chromium.org2010-01-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | This gets the window from the RenderWidgetHostViewGtk and just does OpenGL calls directly into it. There are a lot of bugs, especially around expose events, which aren't really processed at all, and also tab teardown and reparenting. The new backing store defaults to off. This does some refactoring of the existing Windows GPU process backing store implementation to make some of it sharable by this Linux verion. This removes some previously defunct in-process GL backing store code and moves it to the GPU process. This patch does some refactoring around how child processes are created using zygoes or not. I found there were many places where a command line would be checked with special logic to know whether to enable zygote code or not. I tried to unify this so it could be computed once for each process type. This is what most of the changed files in chrome/browser are related to. BUG=none TEST=none Review URL: http://codereview.chromium.org/548112 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37088 0039d316-1c4b-4281-b951-d872f2087c98
* Add the ability for the GPU process to be used to paint the backing store of abrettw@chromium.org2010-01-131-0/+73
tab. This is the first pass and is currently a bit buggy and incomplete. This patch refactors the backing store to make it a virtual interface which is then implemented by the platform-specific backing stores. This cleans up the multi-platform aspects of the old code, and also makes it possible to create different backing stores (such as ones in another process). This renames the BackingStore::PaintRect function to PaintToBackingStore which clears up what it does. I would often get confused and think that it paints the backing store to the screen. This makes a common way to capture backing store information and adds it to the backing store API. This removed a bunch of ugly ifdefs. This adds the ability for a backing store to specify that the TransportDIB should not be freed by RenderWidgetHost when painting is complete. This is necessary since the out-of-process version needs to use it after the RenderWidget paint function has returned. This pushes up the vector of copy_rect from RenderWidgetHost to the actual BackingStores. This prevents us from sending duplicate data over IPC. It also makes the common non-IPC case more efficient, since we end up setting up various surfaces only once when there are multiple update rects. BUG=none TEST=none Review URL: http://codereview.chromium.org/523028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36075 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-31 09:46:07 +0000