summaryrefslogtreecommitdiffstats
path: root/chrome/common/gpu_messages_internal.h
Commit message (Collapse)AuthorAgeFilesLines
* Move GPU messages to content. I've also switched the IPC structs to use the ↵jam@chromium.org2011-03-101-381/+0
| | | | | | | | new IPC macros that generate serialization code. Review URL: http://codereview.chromium.org/6673003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@77721 0039d316-1c4b-4281-b951-d872f2087c98
* Make GPUInfo a struct, which it should be according to the C++ guidelines. ↵jam@chromium.org2011-03-081-1/+1
| | | | | | | | This makes it easy to write automated serilization code for it. Review URL: http://codereview.chromium.org/6621057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@77300 0039d316-1c4b-4281-b951-d872f2087c98
* Move preliminary gpu info collection and software rendering flags ↵zmo@google.com2011-03-041-6/+0
| | | | | | | | | | | computation to browser startup time. This allows us to handle each feature independently through appending renderer process commandline switches (in most cases but not all, because this preliminary run only collects partial gpu info). BUG=none TEST=unittest Review URL: http://codereview.chromium.org/6588138 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@76971 0039d316-1c4b-4281-b951-d872f2087c98
* Moved creation of GPU command buffer shared memory into the browser process.apatrick@chromium.org2011-02-281-2/+3
| | | | | | | | | | | This is to allow the GPU process to be sandboxed on all platforms. TEST=try, run WebGL app on win and mac. BUG=none Review URL: http://codereview.chromium.org/6588029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@76307 0039d316-1c4b-4281-b951-d872f2087c98
* Moved creation of GPU transfer buffers into the browser process.apatrick@chromium.org2011-02-241-0/+14
| | | | | | | | | | | | | Transfer buffer creation was previously done in the GPU process. This is one step required to sandbox the GPU process. Rather than the GPU process opening a renderer process's handle by PID, which can't been done when sandboxed on Windows, the browser process passes the handle to the GPU process via the renderer process. TEST=try BUG=none Review URL: http://codereview.chromium.org/6557006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@75980 0039d316-1c4b-4281-b951-d872f2087c98
* Disable the resize IPC for accelerated compositing on TOUCH_UI.backer@chromium.org2011-02-241-1/+1
| | | | | | | | | | | The rendering path for TOUCH_UI is a work in progress, but it will roughly resemble the MAC OS X path. In particular, we will not need the browser to synchronously resize the window that the GPU process is drawing into. This patch makes accelerated rendering closer to usable on TOUCH_UI (the chrome is distorted). BUG=none (accelerated compositing for TOUCH_UI is still NOT_IMPLEMENTED) TEST=by hand on Linux (w/ and w/o TOOLKIT_VIEWS and TOUCH_UI), Windows, and Mac Review URL: http://codereview.chromium.org/6567005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@75884 0039d316-1c4b-4281-b951-d872f2087c98
* Collect as much GPU information as possible without creating a GL/D3D ↵zmo@google.com2011-02-191-0/+6
| | | | | | | | | | | context. If based on such partial information, a graphics card/driver is already blacklisted, we shouldn't even try to establish GPU channel. This gives us the ability to blacklist REALLY BAD graphics card/driver that will crash during GPU info collection. BUG=72979 TEST=none Review URL: http://codereview.chromium.org/6531023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@75473 0039d316-1c4b-4281-b951-d872f2087c98
* Refactoring to use a new IPC message filter.backer@chromium.org2011-01-311-8/+26
| | | | | | | | | | | There were several ViewHostMsgs being sent to the GpuProcessHost via a RenderMessageFilter. This patch creates a GpuMessageFilter and renames the ViewHostMsgs to GpuHostMsgs. This will clean up some of the clutter in render_messages_internal and render_message_filter. It will also allow us to easily add new messages to the GpuProcessHost in the future. BUG=none TEST=by hand and trybots Review URL: http://codereview.chromium.org/6401003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@73152 0039d316-1c4b-4281-b951-d872f2087c98
* Route LOG messages generated on the GPU process to the about:gpu page.nduca@chromium.org2011-01-271-0/+6
| | | | | | | | | BUG=57069 TEST= Review URL: http://codereview.chromium.org/6262017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@72881 0039d316-1c4b-4281-b951-d872f2087c98
* Route IPC through browser when creating a viewable command buffer.backer@chromium.org2011-01-271-28/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The communications path for creating a viewable command buffer used to be directly from the renderer (gpu_channel.cc) to the gpu process (gpu_channel.cc). This patch makes the browser an intermediary: - renderer (gpu_channel.cc) makes a synchronous request to the browser (picked up in renderer_message_filter.cc and forwarded to gpu_process_host.cc) - browser (gpu_process_host.cc) makes an asynchronous request to the gpu process (picked up in gpu_thread.cc and forwarded to gpu_channel.cc) for the command buffer - gpu process (gpu_thread.cc) sends an ACK with the route_id for the command buffer back to the browser (gpu_process_host.cc) - browser (gpu_process_host.cc) sends a delayed reply back to the renderer (gpu_channel_host.cc), which had blocked There are several motivations for this patch: - creating an onscreen command buffer requires a window to draw into (which is acquired/locked in the browser); by routing through the browser, we can acquire the get the window beforehand (thereby preventing a deadlock in some other work that I'm doing) - we can eliminate several separate synchronous IPC messages for obtaining and releasing the window associated with drawing (I've tried to unify the different code paths for Linux, Windows, and Mac) - in the future, we can have the browser allocate SHM for the command buffer and transfer buffers, allowing us to sandbox the gpu process BUG=none TEST=by hand on all 3 platforms, trybots Review URL: http://codereview.chromium.org/6343006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@72798 0039d316-1c4b-4281-b951-d872f2087c98
* Reland 72704 - Defered collect DirectX diagnostics until they are needed for ↵apatrick@chromium.org2011-01-271-1/+3
| | | | | | | | | | | | | | | | | | | about:gpu. This is because collecting the stats often crashes. Added a guard to prevent the collection of diagnostics on multiple threads simultaneously. Renamed GPUInfo::Progress to GPUInfo::Level. TEST=try, about:gpu does not cause concurrent diagnostics collection BUG=none Review URL: http://codereview.chromium.org/6364013 Review URL: http://codereview.chromium.org/6341011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@72731 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 72704 - Defered collect DirectX diagnostics until they are needed for ↵apatrick@chromium.org2011-01-261-3/+1
| | | | | | | | | | | | | | | | | | | | about:gpu. This is because collecting the stats often crashes. Added a guard to prevent the collection of diagnostics on multiple threads simultaneously. Renamed GPUInfo::Progress to GPUInfo::Level. TEST=try, about:gpu does not cause concurrent diagnostics collection BUG=none Review URL: http://codereview.chromium.org/6364013 TBR=apatrick@chromium.org Review URL: http://codereview.chromium.org/6370013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@72707 0039d316-1c4b-4281-b951-d872f2087c98
* Defered collect DirectX diagnostics until they are needed for about:gpu.apatrick@chromium.org2011-01-261-1/+3
| | | | | | | | | | | | | | | This is because collecting the stats often crashes. Added a guard to prevent the collection of diagnostics on multiple threads simultaneously. Renamed GPUInfo::Progress to GPUInfo::Level. TEST=try, about:gpu does not cause concurrent diagnostics collection BUG=none Review URL: http://codereview.chromium.org/6364013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@72704 0039d316-1c4b-4281-b951-d872f2087c98
* Re-land of http://codereview.chromium.org/6094009 with Mac build fix.kbr@google.com2011-01-071-0/+8
| | | | | | | | | | | | | | | | | | | | | Perform GPU-related initialization in GPU process in response to an IPC from the browser. Because Chromium's child process host detects that the child has crashed by watching for IPC channel errors, it is imperative that the GPU process's IPC channel be set up before it does any work that might cause it to crash. If initialization fails, the GPU process quits its message loop and cooperatively exits. Fixed a bug in the GpuProcessHost where it would not unblock renderers waiting for GPU process initialization if the GPU process exited. BUG=65369 TEST=ran test case from bug on machine with no GPU hardware and verified that it no longer hangs the renderer, and that the GPU process exits Review URL: http://codereview.chromium.org/6124002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70747 0039d316-1c4b-4281-b951-d872f2087c98
* Revert http://codereview.chromium.org/6094009 (r70768) due tokbr@google.com2011-01-061-8/+0
| | | | | | | | | | | | compilation error on Mac OS X. BUG=65369 TBR=apatrick TEST=none Review URL: http://codereview.chromium.org/6150001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70681 0039d316-1c4b-4281-b951-d872f2087c98
* Perform GPU-related initialization in GPU process in response to ankbr@google.com2011-01-061-0/+8
| | | | | | | | | | | | | | | | | | | | IPC from the browser. Because Chromium's child process host detects that the child has crashed by watching for IPC channel errors, it is imperative that the GPU process's IPC channel be set up before it does any work that might cause it to crash. If initialization fails, the GPU process quits its message loop and cooperatively exits. Fixed a bug in the GpuProcessHost where it would not unblock renderers waiting for GPU process initialization if the GPU process exited. BUG=65369 TEST=ran test case from bug on machine with no GPU hardware and verified that it no longer hangs the renderer, and that the GPU process exits Review URL: http://codereview.chromium.org/6094009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70678 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: Don't hang gpu process if a tab that shares its renderer process with ↵thakis@chromium.org2010-12-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | 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
* 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
* ipc: Simplify the magic required to create IPC message headers.This gets rid ↵jam@chromium.org2010-12-081-281/+255
| | | | | | | | | of having to include the files in a magic place because of xcode dependency issues, and just makes it simpler to create new IPC message classes. It also gets rid of including the X_messages_internal.h file multiple times, which simplifies things and should make the build a little faster. In a future change, I will remove the "internal.h" files since they're no longer needed. Review URL: http://codereview.chromium.org/5526008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68664 0039d316-1c4b-4281-b951-d872f2087c98
* If compositor window already exists, then simply return it rather than ↵nduca@chromium.org2010-12-061-2/+2
| | | | | | | | | | | 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/+5
| | | | | | | | | | | | | | | | | 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/+10
| | | | | | | | | | | | | | | | | | | 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-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+6
| | | | | | | | | | | | | | | | | | | | | | | 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
* Deleted code associated with --enable-gpu-rendering andkbr@chromium.org2010-11-081-49/+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
* Let every "accelerated IO surface swapped" message have an identifier of the ↵thakis@chromium.org2010-10-281-2/+3
| | | | | | | | | | | | | | | 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 63232 - On Windows, create a new TransportDIB::Handle struct which ↵kkania@chromium.org2010-10-201-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | includes the file mapping HANDLE and the source process ID. Duplicating the handle for the remote process is done in TransportDIB::Map, instead of in various #ifdefs scattered across the code. Also on windows, remove the struct for the TransportDIB::Id which contained both the sequence number and the HANDLE and replace it with just the sequence number. Fix ThumbnailGenerator by mapping the TransportDIB on Windows and adding a method to duplicate the file mapping handle before sending across the channel. Also, add a ScopedHandle and fix some handle leaks. BUG=none TEST=none Review URL: http://codereview.chromium.org/3834003 TBR=kkania@chromium.org Review URL: http://codereview.chromium.org/3943002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63246 0039d316-1c4b-4281-b951-d872f2087c98
* On Windows, create a new TransportDIB::Handle struct which includes the filekkania@chromium.org2010-10-201-7/+4
| | | | | | | | | | | | | | | | | | | | mapping HANDLE and the source process ID. Duplicating the handle for the remote process is done in TransportDIB::Map, instead of in various #ifdefs scattered across the code. Also on windows, remove the struct for the TransportDIB::Id which contained both the sequence number and the HANDLE and replace it with just the sequence number. Fix ThumbnailGenerator by mapping the TransportDIB on Windows and adding a method to duplicate the file mapping handle before sending across the channel. Also, add a ScopedHandle and fix some handle leaks. BUG=none TEST=none Review URL: http://codereview.chromium.org/3834003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63232 0039d316-1c4b-4281-b951-d872f2087c98
* Add Ability to pass in allowed extensions to GPU contexts.gman@chromium.org2010-10-191-2/+5
| | | | | | | | | | | | | | | | | | | | Questions: 1) Is WebGraphicsContext3D only used for WebGL? Currently this patch makes that assumption. 2) I started by adding const char* allowed_extensions to a bunch of functions. Then, at the IPC level added GPUInitParams. Should I use GPUInitParams everywhere? 3) Is the path for gpu_init_params.h ok? TEST=unit tests, manually tested WebGL BUG=none Review URL: http://codereview.chromium.org/3775014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63026 0039d316-1c4b-4281-b951-d872f2087c98
* Resubmit - move MFT h264 code to media/video and connect to gpu video decoder.hclam@chromium.org2010-10-081-2/+2
| | | | | | | | | | | TBR=scherkus BUG=None TEST=None Review URL: http://codereview.chromium.org/3591020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61925 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Move MFT H264 video decoder implementation and connect it to ↵hclam@chromium.org2010-10-081-2/+2
| | | | | | | | | | | | | | | | | | | GpuVideoDecoder" This reverts commit 8462483619e253dca3717d51e340ed839a6cab1d. Revert "Fix build failure." This reverts commit 8dcd363637ac2e59f9472c0793a0b1fd3c2ad4c7. TBR=scherkus BUG=None TEST=None Review URL: http://codereview.chromium.org/3601019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61922 0039d316-1c4b-4281-b951-d872f2087c98
* Move MFT H264 video decoder implementation and connect it to GpuVideoDecoderhclam@chromium.org2010-10-081-2/+2
| | | | | | | | | | | | | | | | | | | | Remove media/mf folder and move the video decode engine to media/video. There are some temporary changes in MftH264DecodeEngine to work with GpuVideoDecoder correctly. Removed tests will be added later. Example program will likely be removed permanently due to maintence problem. This patch depends WebKit and ANGLE changes to be able to present video frames onto screen and still have lot of bugs, those problems will be address later. BUG=53714 TEST=Tree is green. This patch doesn't work yet. Review URL: http://codereview.chromium.org/3432030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61918 0039d316-1c4b-4281-b951-d872f2087c98
* GpuVideoDecoderHost runs on IO thread instead of Render threadhclam@chromium.org2010-10-071-4/+0
| | | | | | | | | | | | Move GpuVideoDecoderHost to IO thread and change GpuVideoServiceHost to be a MessageFilter. BUG=53714 TEST=Tree is green. Will pending on WebKit changes to make this work. Review URL: http://codereview.chromium.org/3462015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61854 0039d316-1c4b-4281-b951-d872f2087c98
* Make FakeGlVideoDecodeEngine works in the hardware video decoding architecturehclam@chromium.org2010-10-071-0/+10
| | | | | | | | | | | | | | Add Preroll IPC message for finishing the initialiation of FakeGlVideoDecodeEngine. Also defined methods in WebVideoFrameImpl to access video frame textures. This change depend on a WebKit change to succesfully display the textures. BUG=53714 TEST=Tree is green. This still needs WebKit changes to work. Review URL: http://codereview.chromium.org/3472016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61853 0039d316-1c4b-4281-b951-d872f2087c98
* Implement GpuVideoDecoderHost and unit testshclam@chromium.org2010-10-071-7/+13
| | | | | | | | | | | | | | Add the following feature to GpuVideoDecoderHost: 1. Video frame allocation / release. 2. ProduceVideoFrame / ConsumeVideoFrame using frames allocated. 3. Change GpuVideoDecoder creation to asynchronous. BUG=53714 TEST=unit_tests --gtest_filter=GpuVideoDecoder* Review URL: http://codereview.chromium.org/3397027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61824 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 61608 - On Windows, create a new TransportDIB::Handle struct which ↵satish@chromium.org2010-10-061-4/+7
| | | | | | | | | | | | | | | | | | | | | | | includes the file mapping HANDLE and the source process ID. Duplicating the handle for the remote process is done in TransportDIB::Map, instead of in various #ifdefs scattered across the code. Also on windows, remove the struct for the TransportDIB::Id which contained both the sequence number and the HANDLE and replace it with just the sequence number. Fix ThumbnailGenerator by mapping the TransportDIB on Windows and adding a method to duplicate the file mapping handle before sending across the channel. BUG=none TEST=none Review URL: http://codereview.chromium.org/3305020 BUG=58128 TBR=kkania@chromium.org Review URL: http://codereview.chromium.org/3596008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61624 0039d316-1c4b-4281-b951-d872f2087c98
* On Windows, create a new TransportDIB::Handle struct which includes the filekkania@chromium.org2010-10-061-7/+4
| | | | | | | | | | | | | | | | | mapping HANDLE and the source process ID. Duplicating the handle for the remote process is done in TransportDIB::Map, instead of in various #ifdefs scattered across the code. Also on windows, remove the struct for the TransportDIB::Id which contained both the sequence number and the HANDLE and replace it with just the sequence number. Fix ThumbnailGenerator by mapping the TransportDIB on Windows and adding a method to duplicate the file mapping handle before sending across the channel. BUG=none TEST=none Review URL: http://codereview.chromium.org/3305020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61608 0039d316-1c4b-4281-b951-d872f2087c98
* Add offscreen context creation attributes to GGL.enne@chromium.org2010-10-011-1/+5
| | | | | | | | | | | View contexts and more extensive color format picking not handled yet. BUG=39849 TEST=WebGL conformance tests (context*.html) Review URL: http://codereview.chromium.org/3302019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61220 0039d316-1c4b-4281-b951-d872f2087c98
* Implement video frame exchange in GpuVideoDecoder and testshclam@chromium.org2010-09-291-15/+13
| | | | | | | | | | | | Implement ProduceVideoFrame() in GpuVideoDecoder and unit tests for testing the loginc in GpuVideoDecoder. BUG=53714 TEST=unit_tests --gtest_filter=GpuVideoDecoder* Review URL: http://codereview.chromium.org/3414003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60902 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 60421 - Revert 60373, trying to track down a perf regression (see bug ↵thakis@chromium.org2010-09-241-0/+3
| | | | | | | | | | | | | | | | | 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-3/+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/+3
| | | | | | | | | 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
* Revert r60126 that broke the build.hclam@chromium.org2010-09-221-4/+4
| | | | | | | | | | | TBR=scherkus BUG=53714 TEST= Review URL: http://codereview.chromium.org/3393017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60130 0039d316-1c4b-4281-b951-d872f2087c98
* SendAllocateVideoFrames to the rendererhclam@chromium.org2010-09-211-4/+4
| | | | | | | | | | | This is separated from a previous patch due to link error on mac. BUG=53714 TEST=Mac build bots are happy Review URL: http://codereview.chromium.org/3414011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60126 0039d316-1c4b-4281-b951-d872f2087c98
* Resubmit GpuVideoDecoder and related patches.hclam@chromium.org2010-09-171-1/+1
| | | | | | | | | BUG=53714 TEST=Tree is green Review URL: http://codereview.chromium.org/3442006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59860 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 59784 - GpuVideoDecoder to use GpuVideoDevice and IPC messages to ↵mlloyd@chromium.org2010-09-171-1/+1
| | | | | | | | | | | | | | | | | | complete VideoFrame allocation GpuVideoDecedoer now sends IPC messages to allocation GL textures. It also uses GpuVideoDevice to create VideoFrames from the GL textures. These GL textures are passed into VideoDecodeEngine. BUG=53714 TEST=Tree is green Review URL: http://codereview.chromium.org/3335019 TBR=hclam@chromium.org Review URL: http://codereview.chromium.org/3451007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59790 0039d316-1c4b-4281-b951-d872f2087c98
* GpuVideoDecoder to use GpuVideoDevice and IPC messages to complete ↵hclam@chromium.org2010-09-171-1/+1
| | | | | | | | | | | | | | | VideoFrame allocation GpuVideoDecedoer now sends IPC messages to allocation GL textures. It also uses GpuVideoDevice to create VideoFrames from the GL textures. These GL textures are passed into VideoDecodeEngine. BUG=53714 TEST=Tree is green Review URL: http://codereview.chromium.org/3335019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59784 0039d316-1c4b-4281-b951-d872f2087c98
* Add IPC messages for allocation video frames for hardware video decoderhclam@chromium.org2010-09-171-1/+16
| | | | | | | | | | | | | | | Allocation of video frames should be originated from the VideoDecodeEngine in the GPU process. Adding messages that will allow allocation be done during runtime instead of initialization. Also did some cleanup in gpu_video_common.cc. BUG=53714 TEST=Tree is green Review URL: http://codereview.chromium.org/3361017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59775 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/+8
| | | | | | | | | | | | | | | | | | 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
generated by cgit v1.1 at 2025-01-29 20:47:36 +0000