summaryrefslogtreecommitdiffstats
path: root/chrome/gpu/gpu_channel.h
Commit message (Collapse)AuthorAgeFilesLines
* Add offscreen context creation attributes to GGL.enne@chromium.org2010-10-011-0/+2
| | | | | | | | | | | 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
* 1. ipc_video_decoder.cc/h is media pipeline filter which use the gpu decoder ↵jiesun@google.com2010-08-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | facilities in video stack. it is only enabled when (a) hardware composition is on (b) hardware decoding command line is on (c) h264 codec is specified. 2. gpu_video_service.cc/h is a singleton in gpu process which provide video services for renderer process, through it we could create decoder. ( in my imagination, in the future, we could create encoder or capturer too) 3. gpu_video_decoder.cc/h. abstract interface for hardware decoder. 4. gpu_video_service_host.cc/h is singleton in renderer process which provide proxy for gpu_video_service. 5. gpu_video_decoder_host.cc/h is proxy for gpu_video_decoder. (1 to 1 map).basically there is one global GpuVideoService in GPU process, one GpuVideoServiceHost in Renderer process. for each renderer process, there are could be multiple renderer view, each could had multiple GpuVideoDecoderHost the connect to GpuVideoDeocder through GPUCHannelHOst/GpuChannel. 6. gpu_video_common.cc/h: IPC message definition and pickle/marshaling support. ISSUES: 1. in media pipeline, we need let decoder to determine if bit stream filter should be used instead of let command line to determine it. 2. stop readback from D3D surface use ANGLE. 3. Flush logic still need fine tuning. 4. CreateThread in GpuVideoDecoder, and post message in message handler, and derived classs handle message loop. ? 5. Error handling. 6. Input ring buffer implementation. Current impl is naive. 7.Add output queue for MFT decoder. 8. Query Capabilities at GetVideoServices()... BUG=None TEST=Windows7 Review URL: http://codereview.chromium.org/2873089 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55516 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 55405 - Special thanks for in-ming cheng's MFT hardware decodering code.ananta@chromium.org2010-08-091-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. ipc_video_decoder.cc/h is media pipeline filter which use the gpu decoder facilities in video stack. it is only enabled when (a) hardware composition is on (b) hardware decoding command line is on (c) h264 codec is specified. 2. gpu_video_service.cc/h is a singleton in gpu process which provide video services for renderer process, through it we could create decoder. ( in my imagination, in the future, we could create encoder or capturer too) 3. gpu_video_decoder.cc/h. abstract interface for hardware decoder. 4. gpu_video_decoder_mft.cc/h media foundation transform hardware decoder which run on windows 7 only. 5. gpu_video_service_host.cc/h is singleton in renderer process which provide proxy for gpu_video_service. 6. gpu_video_decoder_host.cc/h is proxy for gpu_video_decoder. (1 to 1 map).basically there is one global GpuVideoService in GPU process, one GpuVideoServiceHost in Renderer process. for each renderer process, there are could be multiple renderer view, each could had multiple GpuVideoDecoderHost the connect to GpuVideoDeocder through GPUCHannelHOst/GpuChannel. 7. gpu_video_common.cc/h: IPC message definition and pickle/marshaling support. ISSUES: 1. in media pipeline, we need let decoder to determine if bit stream filter should be used instead of let command line to determine it. 2. stop readback from D3D surface use ANGLE. 3. Flush logic still need fine tuning. 4. CreateThread in GpuVideoDecoder, and post message in message handler, and derived classs handle message loop. ? 5. Error handling. 6. Input ring buffer implementation. Current impl is naive. 7.Add output queue for MFT decoder. 8. Query Capabilities at GetVideoServices()... BUG=None TEST=Windows7 Review URL: http://codereview.chromium.org/2873089 TBR=jiesun@google.com Review URL: http://codereview.chromium.org/3020077 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55419 0039d316-1c4b-4281-b951-d872f2087c98
* Special thanks for in-ming cheng's MFT hardware decodering code.jiesun@google.com2010-08-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. ipc_video_decoder.cc/h is media pipeline filter which use the gpu decoder facilities in video stack. it is only enabled when (a) hardware composition is on (b) hardware decoding command line is on (c) h264 codec is specified. 2. gpu_video_service.cc/h is a singleton in gpu process which provide video services for renderer process, through it we could create decoder. ( in my imagination, in the future, we could create encoder or capturer too) 3. gpu_video_decoder.cc/h. abstract interface for hardware decoder. 4. gpu_video_decoder_mft.cc/h media foundation transform hardware decoder which run on windows 7 only. 5. gpu_video_service_host.cc/h is singleton in renderer process which provide proxy for gpu_video_service. 6. gpu_video_decoder_host.cc/h is proxy for gpu_video_decoder. (1 to 1 map).basically there is one global GpuVideoService in GPU process, one GpuVideoServiceHost in Renderer process. for each renderer process, there are could be multiple renderer view, each could had multiple GpuVideoDecoderHost the connect to GpuVideoDeocder through GPUCHannelHOst/GpuChannel. 7. gpu_video_common.cc/h: IPC message definition and pickle/marshaling support. ISSUES: 1. in media pipeline, we need let decoder to determine if bit stream filter should be used instead of let command line to determine it. 2. stop readback from D3D surface use ANGLE. 3. Flush logic still need fine tuning. 4. CreateThread in GpuVideoDecoder, and post message in message handler, and derived classs handle message loop. ? 5. Error handling. 6. Input ring buffer implementation. Current impl is naive. 7.Add output queue for MFT decoder. 8. Query Capabilities at GetVideoServices()... BUG=None TEST=Windows7 Review URL: http://codereview.chromium.org/2873089 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55405 0039d316-1c4b-4281-b951-d872f2087c98
* Initial port of accelerated compositor to Mac OS X 10.6. Reusedkbr@google.com2010-08-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* `#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
* GPU process command buffer stubs are destroyed when channel is closed.apatrick@chromium.org2010-07-151-3/+3
| | | | | | | | | | | | | | | | - This was didn't work by of a reference counting cycle. GPU process no longer automatically terminates when the last channel is closed. - The GPU process will be launched at renderer startup and keep running unless it crashes. Command buffer stubs no longer hold a strong reference to their parent. TEST=try BUG=none Review URL: http://codereview.chromium.org/2903006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52531 0039d316-1c4b-4281-b951-d872f2087c98
* Calling OpenGL from the renderer processapatrick@chromium.org2010-03-251-18/+14
| | | | | | | | | | | | | | - 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
* Added support for opening a GPU command buffer from a renderer processes ↵apatrick@chromium.org2010-03-051-0/+104
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