summaryrefslogtreecommitdiffstats
path: root/content/browser/renderer_host/compositing_iosurface_layer_mac.mm
Commit message (Collapse)AuthorAgeFilesLines
* Simplify IOSurface CoreAnimation code: Part 1ccameron2014-08-281-300/+0
| | | | | | | | | | | | | | | | | This is now only used in the context of the browser compositor, so move the code there. Move the software layer code over to compositor as well. Rename structures to de-empahsize 'compositing' (everything is running through the compositor now). BUG=314190 TBR=kbr@chromium.org Review URL: https://codereview.chromium.org/511923004 Cr-Commit-Position: refs/heads/master@{#292482}
* Fix crash in GotAcceleratedIOSurfaceFrameccameron@chromium.org2014-08-081-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The root cause here is that it was assumed that creation of a CompositingIOSurfaceMac and CompositingIOSurfaceContext cannot not fail when, in fact, it can. This resulted in a NULL reference later on. Fix part of this by making CompositingIOSurfaceLayer's init function fail if the CompositingIOSurfaceContext fails. Fix the remaining part of this by removing the NULL references from BrowserCompositorViewMacInternal::GotAcceleratedIOSurfaceFrame, and make the function call AcceleratedLayerHitError if any errors are encountered, which will cause the layer to re-attempt the frame with a new context. Also, split AcceleratedLayerDidDrawFrame into two functions, AcceleratedLayerDidDrawFrame and AcceleratedLayerHitError, rather than parameterizing success using a bool, since that naming was deceptive. BUG=401630 Review URL: https://codereview.chromium.org/447113004 Cr-Commit-Position: refs/heads/master@{#288328} git-svn-id: svn://svn.chromium.org/chrome/trunk/src@288328 0039d316-1c4b-4281-b951-d872f2087c98
* Make resize (very) smooth in ÜCccameron@chromium.org2014-07-291-3/+26
| | | | | | | | | | | | | | | | | | | | Make the ui::Compositor used by BrowserCompositorViewMac use the TaskRunner provided by RenderWidgetResizeHelper. Bracket the call to RenderWidgetResizeHelper that pumps the nested task runner in a BeginPumpingFrames/EndPumpingFrames block to instruct the view to ack frames immediately and defer draws until the resize is finished. Plumb this through to the CompositingIOSurfaceLayerHelper class where the logic is implemented. Update RenderWidgetHostViewMac::HasAcceleratedSurface to compare with the size of the frame drawn by BrowserCompositorViewMac. BUG=392031, 390071, 388005 Review URL: https://codereview.chromium.org/419103005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@286155 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: Fix janky YouTube animationsccameron@chromium.org2014-07-231-3/+32
| | | | | | | | | | | | | | | | | | | | | | Based on experimentation, it appears that calling setNeedsDisplay or displayIfNeeded on a CAOpenGLLayer which has the isAsynchronous property set, will result in the animation getting screwed up. In particular, calls to canDrawInCGLContext stop occurring. This was working in M35 and M36 because, entirely accidentally, we were calling setAsynchronous:NO before most instances of setNeedsDisplay and displayIfNeeded. In r272469, these calls were removed, and resulting in the janky animation. Add calls to setAsynchronous:NO before all instances of calling displayIfNeeded, and almost all instances of calling setNeedsDisplay. BUG=395827 TEST=manual, automated tests in progress Review URL: https://codereview.chromium.org/408153002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@284916 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: Fix bad framerate when capturing tabccameron@chromium.org2014-07-231-8/+7
| | | | | | | | | | | | | | | | | | The fix for this issue, namely, that we must draw contents manually and immediately when a window is occluded because Cocoa will not draw them for us, was not ported to the browser compositor. Plumb this explicitly through a ShouldAckImmediately callback for CompositingIOSurfaceLayerClient and BrowserCompositorViewMacClient. Also check for vsync disabling in the ShouldAckImmediately instead of running it (unnecessarily) through CompositingIOSurfaceContextMac. BUG=393390,350410 Review URL: https://codereview.chromium.org/408103004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@284856 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: Shift more code into C++ classes from ObjC classesccameron@chromium.org2014-07-181-100/+117
| | | | | | | | | | | | | | | | | | | | | | It is difficult to reason about the liftime of ObjC classes, especially NSViews and CALayers. To simplify verifying their correctness, move the bulk of the code for the ObjC classes into C++ helper classes (these classes are already necessary to interface with owning structures). Make the NSView sub-class BrowserCompositorViewCocoa be owned by BrowserCompositorViewMacInternal. Move the bulk of the work in CompositingIOSurfaceLayer to be done by CompositingIOSurfaceLayerHelper, and mark that the ownership relationship should be inverted (that isn't feasible at the moment because we are mid-transition from non-delegated rendering to delegated rendering). BUG=392919 Review URL: https://codereview.chromium.org/394883007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@284063 0039d316-1c4b-4281-b951-d872f2087c98
* Fix hang on Mac when switching CALayersccameron@chromium.org2014-06-211-0/+3
| | | | | | | | | | | | | | | | | | We switch the underlying CALayer used to display content when the DPI of the screen changes. In the CALayer we track whether or not we have a pending swap ack that needs to be sent when the frame is displayed. When we switch layers, we would discard the bit that indicated that there was a pending swap ack to send on display. Ensure that this bit is not lost, by making sure that it is sent to the CALayer's client (the RWHVMac) when the CALayer is disconnected from its client. This bug was introduced in r274802. BUG=385188 Review URL: https://codereview.chromium.org/347763004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@278967 0039d316-1c4b-4281-b951-d872f2087c98
* Delete non-CoreAnimation code in RWHVMacccameron@chromium.org2014-06-071-1/+1
| | | | | | | | | | | | This is dead code now, and is just getting in the way. The non-CA code in ui/cocoa may still be useful for reference and debugging for a little longer, but this stuff is way past that point. BUG= Review URL: https://codereview.chromium.org/311263003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@275639 0039d316-1c4b-4281-b951-d872f2087c98
* Correctly adjust DIP dynamically on Mac ÜCccameron@chromium.org2014-06-051-1/+2
| | | | | | | | | | | | Make contents scale an explicit parameter to the accelerated layer creation. This wasn't necessary in non-ÜC because the IOSurface's size was already initialized there -- in ÜC it isn't. BUG=314190 Review URL: https://codereview.chromium.org/316033003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@275216 0039d316-1c4b-4281-b951-d872f2087c98
* Ack swap buffers after a timeoutccameron@chromium.org2014-06-041-17/+70
| | | | | | | | | | | | | | | | In r272469, a timer that would automatically ack swaps after a quarter-second passed was removed. The purpose of the timer was to manage the transition between async and sync displays, but it had an unintentional side-effect of un-blocking the renderer in the event that the CALayer's display function was never called. Re-add a timer explicitly for this purpose. BUG=378445 Review URL: https://codereview.chromium.org/310183002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@274802 0039d316-1c4b-4281-b951-d872f2087c98
* Use a separate NSView to draw browser composited contentccameron@chromium.org2014-05-231-54/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this, the RenderWidgetHostViewMac was responsible for drawing (with its NSViews and CALayers) the contents coming from the renderer compositor or the browser compositor. This was was getting too messy (lots of state was shared unintentionally). This create a BrowserCompositorViewMac sub-NSView of the RenderWidgetHostViewMac, which is responsible for drawing delegated renderer content coming from the browser. This class still uses the SoftwareLayer and CompositingIOSurfaceLayer classes used to draw content from renderer. In order to make this clean, cut the dependencies from the CompositingIOSurfaceLayer to the RenderWidgetHostViewMac, and hide all needed communication behind a CompositingIOSurfaceLayerClient interface (which is likely to be needed by the BrowserCompositorViewMac). It would seem more reasonable to have BrowserCompositorViewMac live in the ui namespace and directories, but that is not an option yet, because it needs to share so much code with RenderWidgetHostViewMac. Once we switch to using only a delegated renderer, we can move all of this code over to ui. Also, start replacing instances of "composited" with "accelerated". It used to be that these were synonyms, but they are not anymore -- "composited" can be either "accelerated" or "software". BUG=314190 Review URL: https://codereview.chromium.org/294023012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@272469 0039d316-1c4b-4281-b951-d872f2087c98
* CoreAnimation: Evict IOSurfaces after useccameron@chromium.org2014-04-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | CoreAnimation stores contents in CALayers, so it is not necessary to keep around IOSurfaces after they have been drawn (except in the case of being backgrounded and then made visible again). Discard these IOSurfaces if we have more than 8 of them around. Only discard surfaces when they have been drawn and the have no pending copy requests. This relieves an increase in virtual address space used by CoreAnimation. Also move where size and scale factor are assigned so that the size of the IOSurface can be un-set when it is freed. BUG=364808 Review URL: https://codereview.chromium.org/243133008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@265842 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: Add tracing of the CoreAnimation presentation stateccameron@chromium.org2014-04-241-0/+15
| | | | | | | | | | | | | | | | | | Track two pieces of state useful in debugging Mac drawing performance: (1) the period over which a swap ack is pending and (2) the instants at which CoreAnimation queries if we have content to draw. Ideally these would be trace instants and async events on a pseudo-thread, but that functionality is incomplete. Instead, use a counter to indicate the state, and instantaneous jumps in the counter for the instants. BUG= Review URL: https://codereview.chromium.org/246933010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@265829 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: Recreate browser-side GL contexts on GPU switchccameron@chromium.org2014-04-101-3/+0
| | | | | | | | | | | | | | | | When a GPU switch is detected, poison all browser-side GL contexts, which will cause them to be recreated. Make CompositorSwapBuffers destroy and recreate the GL context if it has been poisoned. Ensure that the CALayer for the old content remain in place until the new layer is in place and correctly sized, to avoid flickering. BUG=361493 Review URL: https://codereview.chromium.org/231863002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@262901 0039d316-1c4b-4281-b951-d872f2087c98
* CoreAnimation: Clean up layer resizingccameron@chromium.org2014-03-271-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-landing this without removing the setContentsGravity call, since it is required to appropriately resize devtools. Previous landing was r259824. Make the CoreAnimation layer always have the same size as the IOSurface that is being drawn into it, rather than having it have the same size as the window. Similarly, make the CoreAnimation layers have the same contents scale as the content they are drawing (not necessarily the same scale as the monitor they are being drawn on). With these changes, it is guaranteed that once the IOSurface has been drawn to its layer, the IOSurface will not be needed until the tab is hidden. This allows us to, in a future change, discard the IOSurfaces much more aggressively. Also, clean up the uses of ScopedCAActionDisabler, and put a comment before all remaining instances, explaining exactly what they are disabling. Clean up some other unused calls. TBR=dgozman@chromium.org BUG=245900 TEST=Window drag across montiors, tab drag, killing GPU process Review URL: https://codereview.chromium.org/214673003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@260030 0039d316-1c4b-4281-b951-d872f2087c98
* Revert of CoreAnimation: Clean up layer resizing ↵dgozman@chromium.org2014-03-271-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/208323005/) Reason for revert: Unfortunately, this patch broke DevTools resizing. Try to resize docked to bottom DevTools, and you will see the scale magic: frame of one size is rescaled to the view, which has another size. Original issue's description: > CoreAnimation: Clean up layer resizing > > Make the CoreAnimation layer always have the same size as > the IOSurface that is being drawn into it, rather than having it > have the same size as the window. > > Similarly, make the CoreAnimation layers have the same contents > scale as the content they are drawing (not necessarily the same > scale as the monitor they are being drawn on). > > With these changes, it is guaranteed that once the IOSurface > has been drawn to its layer, the IOSurface will not be needed > until the tab is hidden. This allows us to, in a future change, > discard the IOSurfaces much more aggressively. > > Also, clean up the uses of ScopedCAActionDisabler, and put > a comment before all remaining instances, explaining exactly > what they are disabling. Clean up some other unused calls. > > BUG=245900 > TEST=Window drag across montiors, tab drag, killing GPU process > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=259824 TBR=avi@chromium.org,andresantoso@chromium.org,ccameron@chromium.org NOTREECHECKS=true NOTRY=true BUG=245900 Review URL: https://codereview.chromium.org/214913002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@259913 0039d316-1c4b-4281-b951-d872f2087c98
* CoreAnimation: Clean up layer resizingccameron@chromium.org2014-03-271-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Make the CoreAnimation layer always have the same size as the IOSurface that is being drawn into it, rather than having it have the same size as the window. Similarly, make the CoreAnimation layers have the same contents scale as the content they are drawing (not necessarily the same scale as the monitor they are being drawn on). With these changes, it is guaranteed that once the IOSurface has been drawn to its layer, the IOSurface will not be needed until the tab is hidden. This allows us to, in a future change, discard the IOSurfaces much more aggressively. Also, clean up the uses of ScopedCAActionDisabler, and put a comment before all remaining instances, explaining exactly what they are disabling. Clean up some other unused calls. BUG=245900 TEST=Window drag across montiors, tab drag, killing GPU process Review URL: https://codereview.chromium.org/208323005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@259824 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: Don't wait for new frames inside draw functionsccameron@chromium.org2014-03-251-62/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, we would wait for new frames to come in during the display function for a layer. This is bad in that the display function should be quick and worse in that getting the new frame may mess up state that the display function is relying on. This moves the stall to the view's setFrameSize and WasShown function, where no graphics state is being relied on. Create a new helper function called PauseForPendingResizeOrRepaints in RenderWidgetHostImpl to wait for frames that have already been requested (either by WasResized, during initialization, or, in the future, if the IOSurface has been evicted, during WasShown). This functionality (keeping the surface and the window size in sync) had been disabled on 10.6 due to crashes being detected on the crash server where the current GL context before and after the run loop pump did not line up. This can now be re-enabled on 10.6. Delete the state and functions associated with tracking if we are in a recursive draw call (being asked to draw a new frame that came in while we're drawing a frame). Change DidUpdateBackingStore to always post a message to re-draw the full view when a frame comes in. In theory this path should never be called, but it is still hit by some tests. This will keep the path still working. BUG=245900 Review URL: https://codereview.chromium.org/208323004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@259104 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 258512 "CoreAnimation: Don't wait for frames during draw"engedy@chromium.org2014-03-211-1/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | > CoreAnimation: Don't wait for frames during draw > > Before this change, we would wait for new frames to come in > during the display function for a layer. This is bad in that the > display function should be quick and in that getting the new > frame may mess up state that the display function is relying on. > > This moves the stall to the view's setFrameSize andn WasShown > function, where no graphics state is being relied on. > > This functionality (keeping the surface and the window size in > sync) had been disabled on 10.6 due to crashes being detected > on the crash server where the current GL context before and > after the run loop pump did not line up. This can now be > re-enabled on 10.6. > > BUG=245900 > > Review URL: https://codereview.chromium.org/196743009 TBR=ccameron@chromium.org Review URL: https://codereview.chromium.org/208093003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@258537 0039d316-1c4b-4281-b951-d872f2087c98
* CoreAnimation: Don't wait for frames during drawccameron@chromium.org2014-03-211-62/+1
| | | | | | | | | | | | | | | | | | | | | | Before this change, we would wait for new frames to come in during the display function for a layer. This is bad in that the display function should be quick and in that getting the new frame may mess up state that the display function is relying on. This moves the stall to the view's setFrameSize andn WasShown function, where no graphics state is being relied on. This functionality (keeping the surface and the window size in sync) had been disabled on 10.6 due to crashes being detected on the crash server where the current GL context before and after the run loop pump did not line up. This can now be re-enabled on 10.6. BUG=245900 Review URL: https://codereview.chromium.org/196743009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@258512 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 257194 "Revert 252239 "Do not share a GL context between ..."ccameron@chromium.org2014-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a big up-tick in crashes when this was reverted. BUG=353485 > Revert 252239 "Do not share a GL context between CoreAnimation a..." > > This change was indeed not necessary -- the reason for the crashes was that > the CompositingIOSurfaceLayer had overriden the context method of > CAOpenGLLAyer. > > > Do not share a GL context between CoreAnimation and async readback > > > > There is nothing in the documentation that suggests that this > > change is necessary -- nothing says that you can't use the GL > > context that CoreAnimation is using outside of CoreAnimation. > > So this patch is not well-informed, in that sense. > > > > That said, the crashes reported did not appear until I merged > > the two GL contexts. Also, locally, they went away as soon as I > > separated them back out. > > > > BUG=340385 > > > > Review URL: https://codereview.chromium.org/164873006 > > TBR=ccameron@chromium.org > > Review URL: https://codereview.chromium.org/199413019 TBR=ccameron@chromium.org Review URL: https://codereview.chromium.org/203283002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257615 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 252239 "Do not share a GL context between CoreAnimation a..."ccameron@chromium.org2014-03-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | This change was indeed not necessary -- the reason for the crashes was that the CompositingIOSurfaceLayer had overriden the context method of CAOpenGLLAyer. > Do not share a GL context between CoreAnimation and async readback > > There is nothing in the documentation that suggests that this > change is necessary -- nothing says that you can't use the GL > context that CoreAnimation is using outside of CoreAnimation. > So this patch is not well-informed, in that sense. > > That said, the crashes reported did not appear until I merged > the two GL contexts. Also, locally, they went away as soon as I > separated them back out. > > BUG=340385 > > Review URL: https://codereview.chromium.org/164873006 TBR=ccameron@chromium.org Review URL: https://codereview.chromium.org/199413019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257194 0039d316-1c4b-4281-b951-d872f2087c98
* CoreAnimation: Ensure that frames are drawn after window resizeccameron@chromium.org2014-03-121-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this bug, the layer will be displayed in a strange state where the the GL contents are inappropriately translated, and the background color, which should never be visible for a CAOpenGLLayer sub-class, is visible. There are two bugs at play. The first bug is in drawInCGLContext where we infer the size of the surface we're drawing to from the layer's bounds. This is not correct, the size of the surface being drawn to is the GL_VIEWPORT when drawInCGLContext is called. Re-cast this as a window size, taking into account contents scale (this can be simplified when the non-CoreAnimation code is not needed). With that fixed, we no longer see strange garbage. Rather, we start seeing just the old frame (so, the bottom bit of the frame corresponding to size of the now-removed infobar is now missing). The second bugs is another instance of the well-established fact that setDisplay will often be dropped on the floor. This happens pretty consistently during the resize. Add the usual fix of immediately calling displayIfNeeded. BUG=350817 Review URL: https://codereview.chromium.org/194593003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@256479 0039d316-1c4b-4281-b951-d872f2087c98
* Try to diagnose crashes on 10.6ccameron@chromium.org2014-03-021-0/+8
| | | | | | | | | | | | | | | Canary is crashing in some strange places on just 10.6. It looks like they are related to our (incredibly fragile) browser resize code, where we run the message loop inside the display callback. Temporarily don't do this on 10.6 to see if the crashes go away. TBR=kbr@chromium.org BUG=348328 NOTRY=True Review URL: https://codereview.chromium.org/180273006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@254391 0039d316-1c4b-4281-b951-d872f2087c98
* Remove context property that is never used ccameron@chromium.org2014-02-281-2/+0
| | | | | | | | | | | | We're seeing crashes in this. Removing it probably won't make it go away, but might move them to something more actionable. BUG=348158 R=kbr git-svn-id: svn://svn.chromium.org/chrome/trunk/src@254274 0039d316-1c4b-4281-b951-d872f2087c98
* Make --disable-gpu-vsync work with CoreAnimationccameron@chromium.org2014-02-221-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | CoreAnimation provides GPU backpressure from the browser process to the renderer process by only acknowledging frames when they are displayed. This mechanism has the side-effect of throttling the renderer to about vsync, because the layer will not request to be displayed much more than once per vsync. Relieve this pressure by not going into isAsynchronous mode when receiving new frames when vsync is disabled. This exposed an issue where unluckily-timed setNeedsDisplay calls could be dropped on the floor, hanging the renderer because it would never get its ack. Work around this by calling setNeedsDisplay and displayIfNeeded explicitly, and, if the draw is not triggered by that, sending the ack explicitly. This bug has never triggered without vsync disabled, but apply the workaround in both situations, to be sure. Use a ScopedClosureRunner to ensure that the swap ack be issued in CompositorSwapBuffers, rather than sprinkling ack calls all over the function. Remove the TODOs because the scoped runner should solve the problem they were working around. BUG=245900 Review URL: https://codereview.chromium.org/171513012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@252784 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 252031.ccameron@chromium.org2014-02-201-29/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the patch to always immediate acknowledge swaps. This immediate ack can be removed if this has landed and things are still green. TBR=piman > Revert 251918 "Do not send a frame swap ack from the browser unt..." > > The bots tells this CL broke most of the webrtc browser tests on Mac. > http://chromegw/i/internal.chromium.webrtc/builders/Mac%20Tester > > > BUG=344912 > TEST=webrtc bots. > > > Do not send a frame swap ack from the browser until the frame is drawn > > > > Code to do this was recently removed because it was no longer being > > used in r241225 (https://codereview.chromium.org/116103002). This is > > now necessary again to throttle renderers when using CoreAnimation. > > > > Frames are acked only when they are drawn. Both the CoreAnimation and > > the non-CoreAnimation paths are changed to behave this way. By virtue > > of the fact that the non-CoreAnimation path draws immediately, this > > should have no functional effect on that path. > > > > This differs from the mechanism deleted in the aforementioned patch in > > two ways. > > > > First, it uses a scoped_ptr of a struct instead of a vector of pairs to > > store the information about the swap being returned. This should improve > > readability in that the ack has struct names instead of just first and > > second in the pair, and in that the scoped_ptr does not suggest support > > for multiple pending swaps (which does not exist). > > > > Second, it does makes RWHVMac ack frames more aggressively when > > inside a draw call, rather than adding a call from RWHImpl to the view, > > to effect the ack (which is what the old way does). > > > > BUG=340133 > > > > Review URL: https://codereview.chromium.org/165703002 > > TBR=ccameron@chromium.org > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=252031 Review URL: https://codereview.chromium.org/168263003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@252302 0039d316-1c4b-4281-b951-d872f2087c98
* Do not share a GL context between CoreAnimation and async readbackccameron@chromium.org2014-02-201-1/+1
| | | | | | | | | | | | | | | | | There is nothing in the documentation that suggests that this change is necessary -- nothing says that you can't use the GL context that CoreAnimation is using outside of CoreAnimation. So this patch is not well-informed, in that sense. That said, the crashes reported did not appear until I merged the two GL contexts. Also, locally, they went away as soon as I separated them back out. BUG=340385 Review URL: https://codereview.chromium.org/164873006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@252239 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 251918 "Do not send a frame swap ack from the browser unt..."xians@chromium.org2014-02-191-48/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bots tells this CL broke most of the webrtc browser tests on Mac. http://chromegw/i/internal.chromium.webrtc/builders/Mac%20Tester BUG=344912 TEST=webrtc bots. > Do not send a frame swap ack from the browser until the frame is drawn > > Code to do this was recently removed because it was no longer being > used in r241225 (https://codereview.chromium.org/116103002). This is > now necessary again to throttle renderers when using CoreAnimation. > > Frames are acked only when they are drawn. Both the CoreAnimation and > the non-CoreAnimation paths are changed to behave this way. By virtue > of the fact that the non-CoreAnimation path draws immediately, this > should have no functional effect on that path. > > This differs from the mechanism deleted in the aforementioned patch in > two ways. > > First, it uses a scoped_ptr of a struct instead of a vector of pairs to > store the information about the swap being returned. This should improve > readability in that the ack has struct names instead of just first and > second in the pair, and in that the scoped_ptr does not suggest support > for multiple pending swaps (which does not exist). > > Second, it does makes RWHVMac ack frames more aggressively when > inside a draw call, rather than adding a call from RWHImpl to the view, > to effect the ack (which is what the old way does). > > BUG=340133 > > Review URL: https://codereview.chromium.org/165703002 TBR=ccameron@chromium.org Review URL: https://codereview.chromium.org/172633002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@252031 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor device scale factor on Mac and fix CoreAnimation bugccameron@chromium.org2014-02-191-21/+4
| | | | | | | | | | | | | | | | | | | | | | Rename some functions to be more meaningful: - RWHVMac::scale_factor -> RWHVMac::ViewScaleFactor - RWHVCocoa::deviceScaleFactor_ -> RWHVMac::backing_store_scale_factor - ::ScaleFactor(NSView*) -> ScaleFactorForView(NSView*) Move code to update the scale factor of the backing store from being in RWHVCocoa::updateTabBackingStoreScaleFactor to be in RWHVMac::UpdateBackingStoreScaleFactor. Work around a bug where updating the contentsScale of a CAOpenGLLayer that dynamically changes its isAsynchronous property results in corruption by re-creating the CAOpenGLLayer when a change in scale factor is detected. BUG=245900 Review URL: https://codereview.chromium.org/171763002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251982 0039d316-1c4b-4281-b951-d872f2087c98
* Do not send a frame swap ack from the browser until the frame is drawnccameron@chromium.org2014-02-191-29/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Code to do this was recently removed because it was no longer being used in r241225 (https://codereview.chromium.org/116103002). This is now necessary again to throttle renderers when using CoreAnimation. Frames are acked only when they are drawn. Both the CoreAnimation and the non-CoreAnimation paths are changed to behave this way. By virtue of the fact that the non-CoreAnimation path draws immediately, this should have no functional effect on that path. This differs from the mechanism deleted in the aforementioned patch in two ways. First, it uses a scoped_ptr of a struct instead of a vector of pairs to store the information about the swap being returned. This should improve readability in that the ack has struct names instead of just first and second in the pair, and in that the scoped_ptr does not suggest support for multiple pending swaps (which does not exist). Second, it does makes RWHVMac ack frames more aggressively when inside a draw call, rather than adding a call from RWHImpl to the view, to effect the ack (which is what the old way does). BUG=340133 Review URL: https://codereview.chromium.org/165703002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251918 0039d316-1c4b-4281-b951-d872f2087c98
* Dynamically set CAOpenGLLAyer to be asynchronousccameron@chromium.org2014-02-141-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The supported non-blocking path for drawing content that updates on the order of 60fps is to create a CAOpenGLLayer and set its asynchronous property to YES. In practice, just calling setNeedsDisplay about about 60fps results in noticeable jank. The downside to setting the CAOpenGLLayer to be asynchronous is that it will be asked, every vsync, if it has anything new to draw (via the canDrawInOpenGLContext callback), resulting in high CPU usage, even when idle. The solution to this is to dynamically set the isAsynchronous property to YES when new frames are seen, and leave it at NO when it has been a while (defined as a quarter second arbitrarily) since a new frame has been generated. Note that when a new frame is generated, the gotNewFrame call is made, while when a re-display is required (say, because the window became visible), only setNeedsDisplay is called. This is to avoid going in to asynchronous mode unnecessarily. Also note that the DelayTimer object is hung off the RWHVMac class instead of the CompositingIOSurfaceLayer object. This is because the DelayTimer class requires a C++ class to hang off of, instead of an Objective C interface. BUG=340133 Review URL: https://codereview.chromium.org/165623002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251323 0039d316-1c4b-4281-b951-d872f2087c98
* Use base::ScopedTypeRef for CGL types.ccameron@chromium.org2014-02-111-4/+20
| | | | | | | | | | | | | | | Use gfx::ScopedCGLSetCurrentContext for setting the current context in the browser process. When calling CGLSetCurrentContext, the pre-existing code inconsitently did either of restoring the context, setting the context to NULL, or leaving the context set. This makes the behavior consistent. It also makes error checking pervasive. BUG=245900 Review URL: https://codereview.chromium.org/147493011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@250399 0039d316-1c4b-4281-b951-d872f2087c98
* Back CAOpenGLLayers by CGL contexts instead of NSGL contextsccameron@chromium.org2014-02-061-55/+13
| | | | | | | | | | | | | | | | | | | | | | | | Change CompositingIOSurfaceContext to have a separate path for creating a CGLContextObj directly, rather than creating a NSOpenGLContext and using its CGLContextObj. Add asserts to prevent trying to grab the NSOpenGLContext when using CoreAnimation. Change the CAOpenGLLayer to create the CGLContextObj at creation, and pass a retained pointer to it and its pixel format when requested, and allow the superclass to handle the release of the pixel format and context. This matches the behavior in WebKit. Change DisplayLinkMac to call CVDisplayLinkRelease instead of CFRelease because here is no documentation that CFRelease may be used with a CVDisplayLink. BUG=245900 Review URL: https://codereview.chromium.org/131453012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@249398 0039d316-1c4b-4281-b951-d872f2087c98
* Fix and separate out VSync code on Macccameron@chromium.org2014-02-051-1/+10
| | | | | | | | | | | | | | | | | | Sending VSync parameters to the renderer was deleted in r286038. This adds that back (the impact of that was fairly limited because the browser's back-pressure effectively causes the VSync). This also pulls the computation out of CompositingIOSurfaceMac, and into a separate DisplayLinkMac class which is hung off of each CompositingIOSurface instance. This results in fewer total display links, though, in practice, only the links for animating visible tabs are running. BUG=340133 Review URL: https://codereview.chromium.org/152373002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@249054 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 248360 "Enable CoreAnimation by default."ccameron@chromium.org2014-02-021-2/+1
| | | | | | | | | | | | | | | | > Enable CoreAnimation by default. > > Replace the flag --use-core-animation with --disable-core-animation. > > BUG=245900 > > Review URL: https://codereview.chromium.org/148303003 TBR=ccameron@chromium.org Review URL: https://codereview.chromium.org/152333002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@248429 0039d316-1c4b-4281-b951-d872f2087c98
* Enable CoreAnimation by default.ccameron@chromium.org2014-02-011-1/+2
| | | | | | | | | | Replace the flag --use-core-animation with --disable-core-animation. BUG=245900 Review URL: https://codereview.chromium.org/148303003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@248360 0039d316-1c4b-4281-b951-d872f2087c98
* Fix GpuTabTest.testScreenshotSync in CoreAnimation.ccameron@chromium.org2014-01-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the process of this, consolidate the latency info tracking used by the software and hardware paths. The test GpuTabTest.testScreenshotSync and numerous pixel tests depend on getting screenshots of the window. These screenshots are taken in the ui::GrabViewSnapshot function, which calls CGWindowListCreateImage. The expectation of these tests is that the contents grabbed using those functions be the pixels rendered by the compositor. Without CoreAnimation, we trigger this screen grab immediately after calling CGLFlushDrawable on the contents area, which satisfies the assumptions of tests. With CoreAnimation, we draw the contents of the window in the CompositingIOSurfaceLayer::drawInCGLContext callback. It is then the responsibility of CoreAnimation and the window server to put the contents on the screen. As far as I have found, there is no way to know when that actually happens. To work around this, repeatedly re-draw the CALayer a fixed number of times, and report that the contents are on the screen after that cycle is complete. Note that each drawing cycle involves calling CompositingIOSurfaceLayer::setNeedsDisplay, and then waiting until the CompositingIOSurfaceLayer::drawInCGLContext call is made. I found empirically that 6 of these cycles is necessary to not fail any of the stress tests, so I doubled the number of cycles to 12. BUG=245900 Review URL: https://codereview.chromium.org/150803002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@248261 0039d316-1c4b-4281-b951-d872f2087c98
* Ensure that CAOpenGLLayer uses the dGPU when appropriate.ccameron@chromium.org2014-01-301-2/+32
| | | | | | | | | | | | | | It is necessary that the context created by copyCGLContextForPixelFormat have a pixel format compatible with the one created by copyCGLPixelFormatForDisplayMask. In particular, make copyCGLPixelFormatForDisplayMask create the CGL equivalent of the pixel format created in CompositingIOSurfaceContext. BUG=338925 Review URL: https://codereview.chromium.org/142413008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@247925 0039d316-1c4b-4281-b951-d872f2087c98
* Fix bug where GL fence objects were shared between contexts.ccameron@chromium.org2014-01-211-1/+0
| | | | | | | | | | | | | | | | | | | | These objects were allocated during DrawIOSurface when copying the IOSurface to a video frame. This pulls the copy to the video frame up to CompositorSwapBuffers, and performs the copy in a separate context. Using the separate context makes a call to glFlush before the copy necessary (to be sure that the copy gets the correct contents), and after, to kick off the async copy. Moving the copy up to the swap make it so that we won't send more frames just because of window damage. BUG=334742 Review URL: https://codereview.chromium.org/137893022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@246077 0039d316-1c4b-4281-b951-d872f2087c98
* Allow drawing IOSurfaces from any IOSurfaceContextccameron@chromium.org2013-11-281-3/+4
| | | | | | | | | | | | | | Create a separate offscreen context, shared by all contexts, to be used for asynchronous readback operations. Move some functions (vsync check and vendor check) from the IOSurface to the IOSurfaceContext where they belong. BUG=318751 Review URL: https://codereview.chromium.org/90003003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@237697 0039d316-1c4b-4281-b951-d872f2087c98
* Core Animation: Fix bugs when transition between softwareccameron@chromium.org2013-07-221-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and accelerated mode Make the composited IOSurface CAlayer be a child of the software layer (completely obscuring it) so that falling back to software mode can be expressed as removing the composited IOSurface CALayer from the hierarchy. Explicitly resize both layers (software and composited), rather than relying on the implicit resize. This way, the transaction can be wrapped in a ScopedCAActionDisabler. Fix a bug where CompositingIOSurfaceLayer can access an invalid pointer. This can happen when the call to GetBackingStore in drawInCGLContext method receives a software frame, which causes the layer to invalidate its structures (and would destroy it were the caller not holding a reference). BUG=260995 TEST=run chrome with "--ignore-gpu-blacklist --disable-force-compositing-mode --use-core-animation", and open webgl_trigger_compositing_toggle.html attached to crbug.com/260995. Rapidly resize the window. There should be no crashes or corruption (there may be choppy animation, though). TEST=run chrome with "--ignore-gpu-blacklist --disable-force-compositing-mode --use-core-animation", and open https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/webgl-conformance-tests.html. Click on the "run" button next to "attribs". There should be no flickers. Also, the text in the boxes should appear and disappear discretely -- they should not fade in and out. Review URL: https://chromiumcodereview.appspot.com/19672017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212980 0039d316-1c4b-4281-b951-d872f2087c98
* Move ownership of compositing GL context to RWHVMacccameron@chromium.org2013-07-171-23/+8
| | | | | | | | | | | | | | | | | | | | | | Move all instances of setView and clearDrawable to RWHVMac as well, so that they are easier to track. The CompositingIOSurfaceLayer will continue to have its own scoped_refptr for the GL context, because it may need to outlive the RWHVMac. The CompositingIOSurfaceMac can be changed to have a weak back-pointer to the RWHVMac in a future change. Make sure that the RWHVMac is unbound from the GL context when CoreAnimation is enabled and when compositing is disabled. BUG= Review URL: https://chromiumcodereview.appspot.com/18505002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212001 0039d316-1c4b-4281-b951-d872f2087c98
* Make window resize using CoreAnimation behave the same as without.ccameron@chromium.org2013-07-021-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | Change the NSView to update the layer when setNeedsDisplay is called and add a call to the layer's setNeedsDisplay in the NSView's setFrameSize. This has the consequnece that drawLayer will be called inside the call to setNeedsDisplay. Make the call to drawLayer (for the composited path) block until a frame of the new window size is received. Add all of this together, and the setFrameSize call will block until a frame of the right size is received. This may not be the best thing, as it blocks the browser's main thread (which will jank any animations in other windows), but it matches the non-CoreAnimation behavior. Of note is that setting the NSView to have the redraw policy of NSViewLayerContentsRedrawDuringViewResize and not adding the setNeedsDisplay call in setFrameSize does not result in the setFrameSize call blocking in time, and so the window contents lag during resize. BUG=254629 Review URL: https://chromiumcodereview.appspot.com/18029025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209678 0039d316-1c4b-4281-b951-d872f2087c98
* Update OS X to use scoped_refptr<T>::get() rather than implicit "operator T*"rsleevi@chromium.org2013-07-021-5/+5
| | | | | | | | | | | | Fixes a number of cases either not caught by the automated tool or that have recently regressed. BUG=206189 TBR=darin Review URL: https://codereview.chromium.org/18346006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209554 0039d316-1c4b-4281-b951-d872f2087c98
* mac: Fix two easy problems when compiling with the 10.9 SDK.thakis@chromium.org2013-06-201-0/+1
| | | | | | | | | | No behavior change. BUG=249803 Review URL: https://chromiumcodereview.appspot.com/16975020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@207356 0039d316-1c4b-4281-b951-d872f2087c98
* Ack frames more aggressively in CoreAnimations.ccameron@chromium.org2013-06-181-3/+1
| | | | | | | | | | | | | | | Send an ack when CompositorSwapBuffers is called, rather than waiting until the frame is actually drawn. In some cases, we will never actually draw the frame, resulting in the renderer not sending us any new frames. Also make the ack functions private because they now have no external callers. BUG=245900 Review URL: https://chromiumcodereview.appspot.com/17279005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@207118 0039d316-1c4b-4281-b951-d872f2087c98
* Delete all CompositingIOSurface state on GL error.ccameron@chromium.org2013-06-181-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | When we encounter a GL error or CGL error, free the CompositingIOSurface, its GL context, and any associated layers. - Change public functions of CompositingIOSurface that can encounter an error to return bools. - Add GotAcceleratedCompositingError function to clean up all GL and IOSurface state. - If DrawIOSurface fails in drawRect, fall back to doing a software draw, which will clear the window to white (as opposed to turning to transparent or corrupted). Remove redundant calls to MapIOSurfaceToTexture -- only the call in SetIOSurface actually did anything. Add CHECK_GL_ERROR_IOSURFACE macro to keep around errors detected in debugging glGetError calls. This doesn't apply (yet) to calls that happen in a CopyContext. BUG=249505 Review URL: https://chromiumcodereview.appspot.com/17109005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@206948 0039d316-1c4b-4281-b951-d872f2087c98
* Don't use a sleep in the browser's main thread to throttle swapbuffers.ccameron@chromium.org2013-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | Throttle by delaying sending the ack of each frame to the renderer until a vsync interval has passed since the last ack was sent. Explicitly disable throttling when threaded compositing is enabled (it was supposed to not kick in because the thread proxy will not send new frames more than once per vsync). Also move informing the renderer of the vsync properties to be immediate (not delayed with the ack) and only send this data when a new frame has been sent (not every time all acks are cleared). This should not have any material impact, and is to make the flow easier to follow. BUG=245900 Review URL: https://chromiumcodereview.appspot.com/16845005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@206338 0039d316-1c4b-4281-b951-d872f2087c98
* Add the flags --use-core-animation=lazy to enable CoreAnimationccameron@chromium.org2013-06-141-2/+4
| | | | | | | | | | | | only when overlapping layers are going to be required. Clean up CoreAnimation init and tear-down code. BUG=245900 Review URL: https://chromiumcodereview.appspot.com/16685002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@206266 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-03-24 10:55:56 +0000