summaryrefslogtreecommitdiffstats
path: root/ui/compositor/compositor.h
Commit message (Collapse)AuthorAgeFilesLines
* compositor: Tick the UI animations from cc, instead of from timer callbacks.sadrul@chromium.org2014-06-031-2/+13
| | | | | | | | | | | | | Update the animations in the UI in response to the animation step in the compositor, instead of from a timer callback. This should make it more difficult for rogue UI animations to negatively impact the system too much. BUG=371071 R=ajuma@chromium.org, piman@chromium.org, sky@chromium.org Review URL: https://codereview.chromium.org/291843012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@274404 0039d316-1c4b-4281-b951-d872f2087c98
* Removes ContextFactory::Get/SetInstancesky@chromium.org2014-06-021-16/+0
| | | | | | | | | | BUG=379399 TEST=none TBR=piman@chromium.org Review URL: https://codereview.chromium.org/307963007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@274283 0039d316-1c4b-4281-b951-d872f2087c98
* Temporarily adds another constructor to Compositorsky@chromium.org2014-05-171-0/+13
| | | | | | | | | | | | | | I'm doing this to avoid a gargantuan patch (see https://codereview.chromium.org/273073002/ for how out of control everything is right now). BUG=none TEST=none R=piman@chromium.org Review URL: https://codereview.chromium.org/285373012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@271245 0039d316-1c4b-4281-b951-d872f2087c98
* Do FinishAllRendering in WM_WINDOWPOSCHANGINGjbauman@chromium.org2014-05-131-2/+3
| | | | | | | | | | This ensures that the last swap completes before the window is resized, so that the window contents aren't scaled. BUG=363704 Review URL: https://codereview.chromium.org/277053003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@270206 0039d316-1c4b-4281-b951-d872f2087c98
* ui/compositor: move the browser compositor thread to the ContextFactorypiman@chromium.org2014-05-101-5/+5
| | | | | | | | | | Trying to get rid of more globals in ui/compositor. BUG=None Review URL: https://codereview.chromium.org/277713002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269608 0039d316-1c4b-4281-b951-d872f2087c98
* Remove SharedBitmapManager global in ui/compositorpiman@chromium.org2014-05-091-1/+3
| | | | | | | | | | | Globals prevent ui::Compositor from being used in multiple threads. BUG=None R=jbauman@chromium.org, sky@chromium.org Review URL: https://codereview.chromium.org/271843002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269153 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Remove the capability to give up and leave compositing mode.danakj@chromium.org2014-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | The request to create a fallback OutputSurface should always succeed and there's no way to leave compositing mode. So remove this capability from cc and instead just LOG(FATAL) if the fallback OutputSurface ends up being NULL. The only case where the fallback OutputSurface isn't created is in the ChromeOS browser compositor, and in this case the GpuProcessTransportFactory will LOG(FATAL) before cc even finds out, so this new LOG(FATAL) should never be hit in practice, but documents our expectations. This removes the call to WebWidget::didExitCompositingMode. R=enne BUG=366130,266666 Review URL: https://codereview.chromium.org/256573003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@266089 0039d316-1c4b-4281-b951-d872f2087c98
* Remove offscreen compositor contexts.danakj@chromium.org2014-04-241-11/+1
| | | | | | | | | | | | | | | After https://codereview.chromium.org/250083002/ cc no longer uses an offscreen context for ganesh filters. Instead using the main onscreen context. So, delete the code to create offscreen contexts for the compositor. R=abarth@chromium.org, boliu@chromium.org, enne@chromium.org, piman@chromium.org, enne, piman BUG=366132,366130 Review URL: https://codereview.chromium.org/251343002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@265974 0039d316-1c4b-4281-b951-d872f2087c98
* Make ReflectorImpl use mailboxespiman@chromium.org2014-04-091-33/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | - fixes ui::Layer::SetTextureMailbox to not be hard-coded for software frames. - adds a ui::Layer::SetTextureSize to update the size without sending a new mailbox (since it doesn't change). - entirely removes ui::Layer::SetExternalTexture and ui::Texture, and derived classes. - significantly changes the ReflectorImpl implementation: * an OwnedMailbox is created on the main thread, using the shared main thread context. * the mailbox is passed to the impl thread, that creates a texture out of it with the OutputSurface context, and does operations on that. * the mailbox is passed to the layer. * if the OutputSurface is recreated (assuming, after a lost context), the OwnedMailbox is recreated, and passed to the impl side again, together with the new surface. * the OwnedMailbox takes care of deleting the texture, whether because of a lost context, or when the ReflectorImpl is shut down. BUG=333408 R=danakj@chromium.org, oshima@chromium.org, sky@chromium.org Review URL: https://codereview.chromium.org/228083002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@262836 0039d316-1c4b-4281-b951-d872f2087c98
* ui: Replace PostedSwapQueue with a SwapState enum.danakj@chromium.org2014-04-021-4/+2
| | | | | | | | | | | | | | | | The posted swap queue can only ever have a single swap in it, which is verified by DCHECKs, and it only has a single swap type in the enum, so this deque is pointless and it is causing mysterious crashes. Refactor the posted swap queue into a single SwapState enum to track if a swap was/is currently posted or not. R=piman@chromium.org BUG=348609 Review URL: https://codereview.chromium.org/214013002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@261063 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 257161 "Revert 256955 "Add shared bitmap managers for bro..."jbauman@chromium.org2014-03-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Turns out the child process was mapping the memory twice, so fixed that. > Revert 256955 "Add shared bitmap managers for browser and render..." > > Seems to be causing renderer crashes and possibly out-of-memory issues. > > > Add shared bitmap managers for browser and renderer processes. > > > > The shared bitmap managers will allow software tiles to be allocated in shared memory, so delegated rendering could be used with them. > > > > BUG=327220 > > R=danakj@chromium.org, jschuh@chromium.org, piman@chromium.org > > > > Review URL: https://codereview.chromium.org/148243013 > > TBR=jbauman@chromium.org > > Review URL: https://codereview.chromium.org/197703004 TBR=jbauman@chromium.org Review URL: https://codereview.chromium.org/200913002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257216 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 256955 "Add shared bitmap managers for browser and render..."jbauman@chromium.org2014-03-141-2/+0
| | | | | | | | | | | | | | | | | | | | Seems to be causing renderer crashes and possibly out-of-memory issues. > Add shared bitmap managers for browser and renderer processes. > > The shared bitmap managers will allow software tiles to be allocated in shared memory, so delegated rendering could be used with them. > > BUG=327220 > R=danakj@chromium.org, jschuh@chromium.org, piman@chromium.org > > Review URL: https://codereview.chromium.org/148243013 TBR=jbauman@chromium.org BUG=352689,352616,352618 Review URL: https://codereview.chromium.org/197703004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257161 0039d316-1c4b-4281-b951-d872f2087c98
* Add shared bitmap managers for browser and renderer processes.jbauman@chromium.org2014-03-131-0/+2
| | | | | | | | | | | The shared bitmap managers will allow software tiles to be allocated in shared memory, so delegated rendering could be used with them. BUG=327220 R=danakj@chromium.org, jschuh@chromium.org, piman@chromium.org Review URL: https://codereview.chromium.org/148243013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@256955 0039d316-1c4b-4281-b951-d872f2087c98
* Use gpu::Mailbox instead of std:string in IPCspiman@chromium.org2014-02-151-2/+6
| | | | | | | | | | | | | | | - easier to read - safer since gpu::Mailbox is constant size and checked in the ParamTraits BUG=None Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=251207 R=danakj@chromium.org, jschuh@chromium.org Review URL: https://codereview.chromium.org/148003006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251451 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 251207 "Use gpu::Mailbox instead of std:string in IPCs"blundell@chromium.org2014-02-141-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Speculative revert to determine whether it is causing the below WebViewTest.AutoSizeSW failure on the Linux Test bots (e.g., http://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29%281%29/builds/30888/steps/browser_tests/logs/AutoSizeSW): FATAL:texture_layer.cc(141)] Check failed: !mailbox.IsValid() || !holder_ref_ || !mailbox.Equals(holder_ref_->holder()->mailbox()). This failure also appeared on the trybot run for this CL. > Use gpu::Mailbox instead of std:string in IPCs > > - easier to read > - safer since gpu::Mailbox is constant size and checked in the ParamTraits > > BUG=None > > Review URL: https://codereview.chromium.org/148003006 TBR=piman@chromium.org Review URL: https://codereview.chromium.org/163433008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251281 0039d316-1c4b-4281-b951-d872f2087c98
* Use gpu::Mailbox instead of std:string in IPCspiman@chromium.org2014-02-141-2/+6
| | | | | | | | | | | - easier to read - safer since gpu::Mailbox is constant size and checked in the ParamTraits BUG=None Review URL: https://codereview.chromium.org/148003006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251207 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 250798 "Revert of Read compositor VSync information from ..."sergeyu@chromium.org2014-02-121-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broke compilation. > Revert of Read compositor VSync information from platform, when possible (https://chromiumcodereview.appspot.com/138903025/) > > Reason for revert: > Reverting due to Windows crashes. See: > > http://crbug.com/343199 > > Original issue's description: > > Read compositor VSync information from platform, when possible > > > > The current query of VSync information through the GL context can be unreliable > > on platforms that can dynamically disable vblanks, or multi-monitor setups. > > Preferentially query the VSync information through the platform windowing > > system (presently: XRandR on CrOS) when possible. > > > > BUG=328953 > > TEST=local build, run on CrOS snow > > > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=250250 > > TBR=oshima@chromium.org,piman@chromium.org,brianderson@chromium.org,sky@chromium.org,mukai@chromium.org > NOTREECHECKS=true > NOTRY=true > BUG=328953 > > Review URL: https://codereview.chromium.org/161413002 TBR=sheu@chromium.org Review URL: https://codereview.chromium.org/161743002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@250810 0039d316-1c4b-4281-b951-d872f2087c98
* Revert of Read compositor VSync information from platform, when possible ↵sheu@chromium.org2014-02-121-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://chromiumcodereview.appspot.com/138903025/) Reason for revert: Reverting due to Windows crashes. See: http://crbug.com/343199 Original issue's description: > Read compositor VSync information from platform, when possible > > The current query of VSync information through the GL context can be unreliable > on platforms that can dynamically disable vblanks, or multi-monitor setups. > Preferentially query the VSync information through the platform windowing > system (presently: XRandR on CrOS) when possible. > > BUG=328953 > TEST=local build, run on CrOS snow > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=250250 TBR=oshima@chromium.org,piman@chromium.org,brianderson@chromium.org,sky@chromium.org,mukai@chromium.org NOTREECHECKS=true NOTRY=true BUG=328953 Review URL: https://codereview.chromium.org/161413002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@250798 0039d316-1c4b-4281-b951-d872f2087c98
* Read compositor VSync information from platform, when possiblesheu@chromium.org2014-02-111-5/+8
| | | | | | | | | | | | | | The current query of VSync information through the GL context can be unreliable on platforms that can dynamically disable vblanks, or multi-monitor setups. Preferentially query the VSync information through the platform windowing system (presently: XRandR on CrOS) when possible. BUG=328953 TEST=local build, run on CrOS snow Review URL: https://codereview.chromium.org/138903025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@250250 0039d316-1c4b-4281-b951-d872f2087c98
* Make LayerTreeHostClient::Animate take TimeTicks instead of doubleajuma@chromium.org2014-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | This makes LayerTreeHostClient::Animate take a TimeTicks instead of a double, moving the conversion to double from the caller of Animate to wherever doubles are actually needed. This avoids precision loss caused by converting from TimeTicks to double and back again when TimeTicks are actually needed (as in LayerTreeHostClientForTesting::Animate) fixing the suspected cause of flakiness in LayerTreeHostAnimationTestFrozenAnimationTickTime. R=danakj,jamesr TBR=sky BUG=341517 Review URL: https://codereview.chromium.org/153633006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@249660 0039d316-1c4b-4281-b951-d872f2087c98
* Pass gfx structs by const ref (gfx::Vector2d)ajay.berwal@samsung.com2014-02-051-1/+1
| | | | | | | | | | | | | | | | | | Avoid unneccessary copy of structures gfx::Vector2d by passing them by const ref rather than value. Any struct of size > 4 bytes should be passed by const ref. Passing by ref for these structs is faster than passing by value, especially when invoking function has multiple parameters. Pass gfx structs by const ref (gfx::Vector2d) BUG=159273 Review URL: https://codereview.chromium.org/132163009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@248941 0039d316-1c4b-4281-b951-d872f2087c98
* Remove ui::Compositor::ReadPixelsenne@chromium.org2014-01-311-5/+0
| | | | | | | | | | | | | | | All callers now use asynchronous CopyOutputRequest on a layer and so this function can be removed entirely. PendingSwap could probably be simplified more as there is only one type in the short term, but PendingSwap will go away entirely once ui::Compositor becomes a SchedulerClient and so it's left as-is. BUG=332167 Review URL: https://codereview.chromium.org/127143002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@248109 0039d316-1c4b-4281-b951-d872f2087c98
* Remove some stray blink::WebGraphicsContext3D references from ui/jamesr@chromium.org2014-01-301-4/+0
| | | | | | | | | | This type isn't used anywhere and doesn't need to be forward declared. TBR=sky Review URL: https://codereview.chromium.org/142713005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@247890 0039d316-1c4b-4281-b951-d872f2087c98
* ui: Move DrawWaiterForTest out of compositor.h/ccdanakj@chromium.org2014-01-241-37/+0
| | | | | | | | | | | | Put this class in its own files in ui/compositor/test/. R=enne TBR=sky BUG= Review URL: https://codereview.chromium.org/138903017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@246823 0039d316-1c4b-4281-b951-d872f2087c98
* Remove uses of WebGraphicsContext3D from ui/compositorjamesr@chromium.org2013-12-141-1/+0
| | | | | | | | | | | | | | This removes all uses of blink::WebGraphicsContext3D as the context type from ui/compositor/ and dependent code, excluding some test harness setup. The compositor implementation uses gpu::gles2::GLES2Interface*, defined in gpu/command_buffer/client/, as the context type to avoid dependencies on the blink repository. BUG=181120 Review URL: https://codereview.chromium.org/107513008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240826 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup: Remove unused forward declarations from compositor.htfarina@chromium.org2013-12-111-21/+6
| | | | | | | | | | | | | Plus remove a few ui:: prefix where it isn't necessary and two unnecessary includes. BUG=None TEST=compositor_unittests R=danakj@chromium.org Review URL: https://codereview.chromium.org/112613002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@240136 0039d316-1c4b-4281-b951-d872f2087c98
* Fall back to software mode if Aura can't create a GL contextccameron@chromium.org2013-12-031-1/+1
| | | | | | | | | | | | | Wire up fallback from Compositor::CreateOutputSurface to ContextFactory::CreateOutputSurface, so that we force using the software compositor after failing to create a GL context enough times. BUG=319267 Review URL: https://codereview.chromium.org/93593002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@238382 0039d316-1c4b-4281-b951-d872f2087c98
* RenderWidget and RenderWidgetCompositor cleanuptrchen@chromium.org2013-11-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch can be considered as two logical changes that are orthogonal. Both of the changes don't affect code behavior. [2/2] Add LayerTreeHostSingleThreadClient::ScheduleAnimation widget_->scheduleAnimation() should be routed through SingleThreadProxy:: SetNeedsAnimate(). This way we can reduce many CC API inconsistencies between single thread and threaded mode. [1/2] Remove ScheduleCompositeImpl The force_redraw parameter of ScheduleCompositeImpl only makes a difference in threaded-compositing mode. The only user of ScheduleCompositeImpl(true) always calls SetNeedsAnimate, so it doesn't harm to call it one more time. --> ScheduleCompositeImpl is fully equivalent to scheduleComposite This patch merges ScheduleCompositeImpl into scheduleComposite. R=jamesr,piman Review URL: https://codereview.chromium.org/80173002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@236718 0039d316-1c4b-4281-b951-d872f2087c98
* Propagate source_frame_number from LTH to DevToolscaseq@chromium.org2013-11-121-1/+1
| | | | | | | | | | | | | | | This plumbs source_frame_number to WebDevToolsAgent::didBeginFrame(), so we can associate impl-side activity with the main frame. BUG=305863 Related blink-side issue: https://codereview.chromium.org/54273005/ R=jamesr@chromium.org, nduca@chromium.org, sky@chromium.org Review URL: https://codereview.chromium.org/54493003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@234469 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 233845 "Use software renderer for windows with an initial..."scottmg@chromium.org2013-11-111-7/+1
| | | | | | | | | | | | | | | | | | | | Various breakage, see linked bugs. > Use software renderer for windows with an initial size less than 64x64 > > If the width or height of a window is less than 64 pixels then some AMD drivers have problems presenting from them, so composite those windows in software. > > BUG=286609 > > Review URL: https://codereview.chromium.org/59913008 BUG=317428,312277 TBR=jbauman@chromium.org Review URL: https://codereview.chromium.org/69203002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@234239 0039d316-1c4b-4281-b951-d872f2087c98
* Use software renderer for windows with an initial size less than 64x64jbauman@chromium.org2013-11-081-1/+7
| | | | | | | | | | If the width or height of a window is less than 64 pixels then some AMD drivers have problems presenting from them, so composite those windows in software. BUG=286609 Review URL: https://codereview.chromium.org/59913008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233845 0039d316-1c4b-4281-b951-d872f2087c98
* Replaces uses of the WGC3DSwapBuffersClient with LTHSingleThreadClientjamesr@chromium.org2013-11-081-2/+2
| | | | | | | | | | | | | | | | | This converts users of the WebGraphicsContext3DSwapBuffersClient mechanism over to using callbacks from cc::LayerTreeHostSingleThreadClient instead. This mechanism is a way to implement flow control when using single threaded compositing by keeping track of the number of pending SwapBuffers calls. WGC3DSwapBuffersClient hooked into the context directly to observer these calls, but intercepted the calls at an awkward place. This instead gets callbacks directly from the compositor when using the single threaded path. R=piman BUG=181120 Review URL: https://codereview.chromium.org/59033012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233777 0039d316-1c4b-4281-b951-d872f2087c98
* Rename WebKit namespace to blink (part 5)abarth@chromium.org2013-11-071-2/+2
| | | | | | | | | | | | This CL updates all references to the WebKit namespace outside of content, chrome, and components. TBR=darin@chromium.org BUG=295096 Review URL: https://codereview.chromium.org/61553006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233518 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce separate client and init path for single-threaded ccjamesr@chromium.org2013-11-071-1/+7
| | | | | | | | | | | | | | | | | | | The chromium compositor can be used in either a single-threaded fashion or multi-threaded. The requirements, APIs and responsibilities of the embedder are different for these two modes. Some users of cc only use one path or the other. This adds a separate client interface and initialization path for code that only uses the single threaded path. Having a dedicated client for the single threaded path will make it possible to get rid of the WebGraphicsContext3DSwapBuffersClient which will then make it easier to break cc's dependency on WGC3D. R=piman BUG=181120 Review URL: https://codereview.chromium.org/61823008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233483 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 230981 "Make TRANSPARENT windows be layered windows on wi..."scottmg@chromium.org2013-11-011-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | > Make TRANSPARENT windows be layered windows on win aura > > This builds on jbauman's patch to plumb use_software_compositor > from here: https://codereview.chromium.org/23621054/ > > The motivation here is that we currently have very different > event, focus, activation paths on DWM vs. classic because of the > differences between when we use top-level windows and when we > don't. With this change, all translucent (i.e. shaped) windows > are converted to being top level (always), and are rendered by > the software compositor and are converted to layered windows for > rendering. > > BUG=293218 and many other focus/activation bugs > > Review URL: https://codereview.chromium.org/26888006 BUG=312277,313349,313462 TBR=scottmg@chromium.org,cpu@chromium.org,ananta@chromium.org Review URL: https://codereview.chromium.org/56623002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@232511 0039d316-1c4b-4281-b951-d872f2087c98
* Move test-only ContextFactory implementations out of production targetsjamesr@chromium.org2013-10-301-71/+0
| | | | | | | | | | | | | | | | | | This moves (Test|Default)ContextFactory and associated setup out of the production compositor target into the test-only compositor_test_support library. This removes the need for us to link in fake/mock classes into the prod build and cleans up several pieces of confusing static state. Code that wants to use one of the test ContextFactory implementations now has to call either ui::InitializeContextFactoryForTests() or, if it's depending on content and using aura, content::ImageTransportFactory::InitializeForUnitTests() and pass in a ContextFactory implementation. Content-based tests get the latter for free through content::BrowserTestBase. R=piman,sky Review URL: https://codereview.chromium.org/45963003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@231867 0039d316-1c4b-4281-b951-d872f2087c98
* Make TRANSPARENT windows be layered windows on win aurascottmg@chromium.org2013-10-251-1/+8
| | | | | | | | | | | | | | | | | | | This builds on jbauman's patch to plumb use_software_compositor from here: https://codereview.chromium.org/23621054/ The motivation here is that we currently have very different event, focus, activation paths on DWM vs. classic because of the differences between when we use top-level windows and when we don't. With this change, all translucent (i.e. shaped) windows are converted to being top level (always), and are rendered by the software compositor and are converted to layered windows for rendering. BUG=293218 and many other focus/activation bugs Review URL: https://codereview.chromium.org/26888006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@230981 0039d316-1c4b-4281-b951-d872f2087c98
* Rename BeginFrame to BeginMainFrame and BeginImplFrame (part 3).dominikg@chromium.org2013-10-231-2/+2
| | | | | | | | | | | | | | | | | Third patch in a series to rename BeginFrame. This patch focuses on cc::ThreadProxy, cc::LayerTreeHost, cc::LayerTreeHostImpl, cc::OutputSurface and it's related (sub)classes. In the scheduler, the term 'BeginFrame' is used for both the main thread and the impl thread. This can cause confusion if it's not obvious which one is being refered to. To clarify this, we rename BeginFrame to BeginMainFrame and BeginImplFrame, respectively. BUG=261765 Review URL: https://codereview.chromium.org/35023002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@230453 0039d316-1c4b-4281-b951-d872f2087c98
* Pulls common compositor integration stuff (draw scheduling, mostly) into ↵ben@chromium.org2013-10-171-13/+10
| | | | | | | | | | | | | | ui::Compositor for two reasons: 1. so it can be used in other RootWindow-like things (e.g. v2 tests) 2. so the RootWindow can be made to optionally have a compositor, to support nested RootWindows. R=piman@chromium.org, sky@chromium.org BUG=none Review URL: https://codereview.chromium.org/27662002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@229242 0039d316-1c4b-4281-b951-d872f2087c98
* Expose only one LayerTreeHostClient::OffscreenContextProvider()jamesr@chromium.org2013-09-271-13/+19
| | | | | | | | | | | | | | | | | | | | | | LayerTreeHostClient currently provides two OffscreenContextProvider getters, one for contexts usable on the main thread and one for contexts usable on the compositor thread. However, the compositor only uses one - the main thread context in single threaded mode and the compositor thread context in threaded mode - and the embedder that implements LTHClient picks which mode the compositor runs in. This reduces the API down to one call and updates the comment to better reflect the requirements. Some compositor embedders, like RenderThreadImpl, do need to keep a main thread context around for other reasons. When they are running the compositor in single threaded mode it's useful to use the same context. This moves the logic for doing that sharing out to the embedders. It turns out there are only two so it's all that much code. R=danakj,piman Review URL: https://codereview.chromium.org/23567027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@225643 0039d316-1c4b-4281-b951-d872f2087c98
* Remove base::Callback from ContextProvider creation.danakj@chromium.org2013-08-161-3/+0
| | | | | | | | | | | | | | | | | | Currently a Callback is given to ContextProvider's creation methods that is able to create a WebGraphicsContext3D and return it to the provider. This callback is called synchronously during the create method, and only one time. Instead of requiring this indirection through a Callback, we can instead just pass a WebGraphicsContext3D to the ContextProvider when it is created, directly. R=piman, sievers BUG=258625 Review URL: https://chromiumcodereview.appspot.com/23247002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217934 0039d316-1c4b-4281-b951-d872f2087c98
* ContextProvider in OutputSurfacedanakj@chromium.org2013-08-161-0/+4
| | | | | | | | | | | | | | | | Instead of putting a raw WebGraphicsContext3D in the OutputSurface given to the compositor, put a ContextProvider. This requires embedders to create ContextProviders instead of raw contexts. No change in behaviour. Covered by existing tests, including cc/ context loss tests. BUG=258625 R=aelias@chromium.org, jamesr@chromium.org, piman@chromium.org, sievers@chromium.org Review URL: https://codereview.chromium.org/20185002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217890 0039d316-1c4b-4281-b951-d872f2087c98
* cc: Rename cc::FakeContextProvider to TestContextProviderdanakj@chromium.org2013-08-131-3/+3
| | | | | | | | | | | | | This name matches the TestWebGraphicsContext3D* that it holds. Also have the context provider explicitly use a TestWGC3D to allow for less PassAs() of scoped pointers, and static casts. BUG=258625 R=jbauman, piman Review URL: https://chromiumcodereview.appspot.com/22937007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217387 0039d316-1c4b-4281-b951-d872f2087c98
* aura,cc: Make TestContextProvider usable outside cc.danakj@chromium.org2013-08-131-3/+1
| | | | | | | | | | | | This makes the TestWebGraphicsContext3D available outside of cc, and replaces ui::TestWGC3D with the class from cc. R=jbauman, piman BUG=258625 Review URL: https://chromiumcodereview.appspot.com/22293007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217308 0039d316-1c4b-4281-b951-d872f2087c98
* aura: Remove CreateOffscreenContext from ui::ContextFactory.danakj@chromium.org2013-08-131-18/+13
| | | | | | | | | | | | | | | | Drop this method since it is not needed in the interface anymore. In order to do this, make the cc::FakeContextProvider externally available so ui::Compositor can make use of it for tests, and revamp it to make it slightly more general. Depends on: https://codereview.chromium.org/22293003/ R=jbauman, piman BUG=258625 Review URL: https://chromiumcodereview.appspot.com/21026005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217202 0039d316-1c4b-4281-b951-d872f2087c98
* Clean up compositor initialization/destruction.danakj@chromium.org2013-08-121-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Moved from https://codereview.chromium.org/21052007/ Currently the ContextFactory is outliving the compositor thread in tests, which is bad since the contexts in there can be bound to the compositor thread. Then we end up reusing those contexts and bad things happen. This enforces ordering for initializing and destroying the compositor as follows: Initialize ContextFactory ..Compositor::Initialize ....Create Compositor instances ....Delete Compositor instances ..Compositor::Terminate The Compositor::Terminate call also destroys the ContextFactory. The ContextFactory can be initialized in one of two ways: 1. ImageTransportFactory::Initialize will set up the ContextFactory. This is used by things that invoke all of content/browser/. 2. Compositor::InitializeContextFactoryForTests() must be explicitly called by any unit tests that create a compositor. Since some tests want a real GL context and some don't, this does away with the misnomer of initializing the Compositor once for the entire test suite, and then re-initializing somewhere in the middle of the test suite. Instead, each test must Initialize/Terminate the compositor with the ContextFactory type of its choice. Incidently, this test enables 20 tests on aura or win_aura that were previously being skipped. TBR=piman@chromium.org BUG=258625 Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=216780 Review URL: https://chromiumcodereview.appspot.com/22293003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217069 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 216780 "Clean up compositor initialization/destruction."nhiroki@chromium.org2013-08-121-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > Clean up compositor initialization/destruction. > > Moved from https://codereview.chromium.org/21052007/ > > Currently the ContextFactory is outliving the compositor thread in > tests, which is bad since the contexts in there can be bound to the > compositor thread. Then we end up reusing those contexts and bad > things happen. > > This enforces ordering for initializing and destroying the > compositor as follows: > > Initialize ContextFactory > ..Compositor::Initialize > ....Create Compositor instances > ....Delete Compositor instances > ..Compositor::Terminate > > The Compositor::Terminate call also destroys the ContextFactory. > > The ContextFactory can be initialized in one of two ways: > 1. ImageTransportFactory::Initialize will set up the > ContextFactory. This is used by things that invoke all of > content/browser/. > 2. Compositor::InitializeContextFactoryForTests() must be > explicitly called by any unit tests that create a compositor. > > Since some tests want a real GL context and some don't, this > does away with the misnomer of initializing the Compositor once > for the entire test suite, and then re-initializing somewhere > in the middle of the test suite. Instead, each test must > Initialize/Terminate the compositor with the ContextFactory > type of its choice. > > Incidently, this test enables 20 tests on aura or win_aura that > were previously being skipped. > > TBR=piman@chromium.org > BUG=258625 > > Review URL: https://chromiumcodereview.appspot.com/22293003 TBR=danakj@chromium.org Review URL: https://codereview.chromium.org/22648006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@216907 0039d316-1c4b-4281-b951-d872f2087c98
* Clean up compositor initialization/destruction.danakj@chromium.org2013-08-091-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Moved from https://codereview.chromium.org/21052007/ Currently the ContextFactory is outliving the compositor thread in tests, which is bad since the contexts in there can be bound to the compositor thread. Then we end up reusing those contexts and bad things happen. This enforces ordering for initializing and destroying the compositor as follows: Initialize ContextFactory ..Compositor::Initialize ....Create Compositor instances ....Delete Compositor instances ..Compositor::Terminate The Compositor::Terminate call also destroys the ContextFactory. The ContextFactory can be initialized in one of two ways: 1. ImageTransportFactory::Initialize will set up the ContextFactory. This is used by things that invoke all of content/browser/. 2. Compositor::InitializeContextFactoryForTests() must be explicitly called by any unit tests that create a compositor. Since some tests want a real GL context and some don't, this does away with the misnomer of initializing the Compositor once for the entire test suite, and then re-initializing somewhere in the middle of the test suite. Instead, each test must Initialize/Terminate the compositor with the ContextFactory type of its choice. Incidently, this test enables 20 tests on aura or win_aura that were previously being skipped. TBR=piman@chromium.org BUG=258625 Review URL: https://chromiumcodereview.appspot.com/22293003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@216780 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 216278 "Clean up compositor initialization/destruction."kalman@chromium.org2013-08-071-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interactive_ui_test failures in TabDragging tests: http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%282%29/builds/17046 > Clean up compositor initialization/destruction. > > Moved from https://codereview.chromium.org/21052007/ > > Currently the ContextFactory is outliving the compositor thread in > tests, which is bad since the contexts in there can be bound to the > compositor thread. Then we end up reusing those contexts and bad > things happen. > > This enforces ordering for initializing and destroying the > compositor as follows: > > Initialize ContextFactory > ..Compositor::Initialize > ....Create Compositor instances > ....Delete Compositor instances > ..Compositor::Terminate > > The Compositor::Terminate call also destroys the ContextFactory. > > The ContextFactory can be initialized in one of two ways: > 1. ImageTransportFactory::Initialize will set up the > ContextFactory. This is used by things that invoke all of > content/browser/. > 2. Compositor::InitializeContextFactoryForTests() must be > explicitly called by any unit tests that create a compositor. > > Since some tests want a real GL context and some don't, this > does away with the misnomer of initializing the Compositor once > for the entire test suite, and then re-initializing somewhere > in the middle of the test suite. Instead, each test must > Initialize/Terminate the compositor with the ContextFactory > type of its choice. > > Incidently, this test enables 20 tests on aura or win_aura that > were previously being skipped. > > TBR=piman@chromium.org > BUG=258625 > > Review URL: https://codereview.chromium.org/22293003 TBR=danakj@chromium.org Review URL: https://codereview.chromium.org/22603007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@216294 0039d316-1c4b-4281-b951-d872f2087c98
* Clean up compositor initialization/destruction.danakj@chromium.org2013-08-071-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Moved from https://codereview.chromium.org/21052007/ Currently the ContextFactory is outliving the compositor thread in tests, which is bad since the contexts in there can be bound to the compositor thread. Then we end up reusing those contexts and bad things happen. This enforces ordering for initializing and destroying the compositor as follows: Initialize ContextFactory ..Compositor::Initialize ....Create Compositor instances ....Delete Compositor instances ..Compositor::Terminate The Compositor::Terminate call also destroys the ContextFactory. The ContextFactory can be initialized in one of two ways: 1. ImageTransportFactory::Initialize will set up the ContextFactory. This is used by things that invoke all of content/browser/. 2. Compositor::InitializeContextFactoryForTests() must be explicitly called by any unit tests that create a compositor. Since some tests want a real GL context and some don't, this does away with the misnomer of initializing the Compositor once for the entire test suite, and then re-initializing somewhere in the middle of the test suite. Instead, each test must Initialize/Terminate the compositor with the ContextFactory type of its choice. Incidently, this test enables 20 tests on aura or win_aura that were previously being skipped. TBR=piman@chromium.org BUG=258625 Review URL: https://codereview.chromium.org/22293003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@216278 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-08 09:51:11 +0000