Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
433543002:
Add a new ozone switch to enable surfaceless output mode. (Closed)
|
Created:
6 years, 4 months ago by achaulk Modified:
6 years, 4 months ago CC:
chromium-reviews, rjkroege, ozone-reviews_chromium.org, nkostylev+watch_chromium.org, jam, sievers+watch_chromium.org, jbauman+watch_chromium.org, darin-cc_chromium.org, oshima+watch_chromium.org, kalyank, piman+watch_chromium.org, danakj+watch_chromium.org, stevenjb+watch_chromium.org, cc-bugs_chromium.org, davemoore+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Project:
chromium Visibility:
Public. |
DescriptionAdd a new ozone switch to enable surfaceless output mode.
This is an output surface that displays the content using
overlays and render-to-FBO, instead of the usual system-managed
framebuffer. Implementation to follow in another CL.
BUG=380861
TBR=stevenjb
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=290072
Patch Set 1 #Patch Set 2 : pull flag from ozone platform instead #Patch Set 3 : switch to ozone flag #
Total comments: 1
Patch Set 4 : #
Total comments: 1
Patch Set 5 : fix typo #Patch Set 6 : fix typo #
Total comments: 5
Patch Set 7 : remove stub code from gpu_process_transport_factory #Patch Set 8 : remove extra line #Patch Set 9 : rebased #Patch Set 10 : re-rebase #
Messages
Total messages: 35 (0 generated)
Just ozone people for now
On 2014/07/30 18:50:50, achaulk wrote: > Just ozone people for now I don't think we should use switches as a back channel between the compositor and the platform. It's going to be a big headache when other components come in ant This is also likely to cause undefined references in things like the demo app. It doesn't link CC at all. So I still think you should just put something in the API:
On 2014/07/30 19:00:13, spang wrote:
> On 2014/07/30 18:50:50, achaulk wrote:
> > Just ozone people for now
>
> I don't think we should use switches as a back channel between the compositor
> and the platform. It's going to be a big headache when other components come
in
> ant
>
> This is also likely to cause undefined references in things like the demo app.
> It doesn't link CC at all.
>
> So I still think you should just put something in the API:
Doh, I hit send accidently gain. Put something in the API:
virtual scoped_ptr<SurfacelessOzoneEGL> CreateSurfacelessEGLForWidget(
gfx::AcceleratedWidget widget);
virtual scoped_ptr<SurfaceOzoneEGL> CreateEGLSurfaceForWidget(
gfx::AcceleratedWidget widget);
On 2014/07/30 19:03:40, spang wrote: > On 2014/07/30 19:00:13, spang wrote: > > On 2014/07/30 18:50:50, achaulk wrote: > > > Just ozone people for now > > > > I don't think we should use switches as a back channel between the compositor > > and the platform. It's going to be a big headache when other components come > in > > ant > > > > This is also likely to cause undefined references in things like the demo app. > > It doesn't link CC at all. > > > > So I still think you should just put something in the API: > > Doh, I hit send accidently gain. Put something in the API: > > virtual scoped_ptr<SurfacelessOzoneEGL> CreateSurfacelessEGLForWidget( > gfx::AcceleratedWidget widget); > > virtual scoped_ptr<SurfaceOzoneEGL> CreateEGLSurfaceForWidget( > gfx::AcceleratedWidget widget); We still need a way to tell the compositor what is expected to be used though
On 2014/07/30 19:06:23, achaulk wrote: > On 2014/07/30 19:03:40, spang wrote: > > On 2014/07/30 19:00:13, spang wrote: > > > On 2014/07/30 18:50:50, achaulk wrote: > > > > Just ozone people for now > > > > > > I don't think we should use switches as a back channel between the > compositor > > > and the platform. It's going to be a big headache when other components come > > in > > > ant > > > > > > This is also likely to cause undefined references in things like the demo > app. > > > It doesn't link CC at all. > > > > > > So I still think you should just put something in the API: > > > > Doh, I hit send accidently gain. Put something in the API: > > > > virtual scoped_ptr<SurfacelessOzoneEGL> CreateSurfacelessEGLForWidget( > > gfx::AcceleratedWidget widget); > > > > virtual scoped_ptr<SurfaceOzoneEGL> CreateEGLSurfaceForWidget( > > gfx::AcceleratedWidget widget); > > We still need a way to tell the compositor what is expected to be used though There's two good ways to do add a switch that does what you want: 1. Add it to CC, and implement it by asking the platform for the new path when the switch is passed. If it's not passed, or isn't supported, then use the old path. 2. Add it to gbm, and have CC always take then new path when new path is supported. If it's not supported, then use the old path. When the switch is off, the platform disables the new path by telling CC it's not supported. If you read the switch in two different places, then you're allowing a split brain scenario to occur: - The flag is passed, but the app isn't updated (suppose the app doesn't use CC). This is the case for mojo_shell, ozone_demo. - The flag is passed, but the platform isn't updated. No compile error or anything, but CC drives the platform code in an unsupported way and nothing works. This is the case for egltest, and soon x11, as well as out of tree platforms. I really don't want a flag that everybody reads, and everything needs to support immediately, or else weird breakage can happen.
On 2014/07/30 19:50:27, spang wrote: > On 2014/07/30 19:06:23, achaulk wrote: > > On 2014/07/30 19:03:40, spang wrote: > > > On 2014/07/30 19:00:13, spang wrote: > > > > On 2014/07/30 18:50:50, achaulk wrote: > > > > > Just ozone people for now > > > > > > > > I don't think we should use switches as a back channel between the > > compositor > > > > and the platform. It's going to be a big headache when other components > come > > > in > > > > ant > > > > > > > > This is also likely to cause undefined references in things like the demo > > app. > > > > It doesn't link CC at all. > > > > > > > > So I still think you should just put something in the API: > > > > > > Doh, I hit send accidently gain. Put something in the API: > > > > > > virtual scoped_ptr<SurfacelessOzoneEGL> CreateSurfacelessEGLForWidget( > > > gfx::AcceleratedWidget widget); > > > > > > virtual scoped_ptr<SurfaceOzoneEGL> CreateEGLSurfaceForWidget( > > > gfx::AcceleratedWidget widget); > > > > We still need a way to tell the compositor what is expected to be used though > > There's two good ways to do add a switch that does what you want: > > 1. Add it to CC, and implement it by asking the platform for the new path when > the switch is passed. If it's not passed, or isn't supported, then use the old > path. > > 2. Add it to gbm, and have CC always take then new path when new path is > supported. If it's not supported, then use the old path. When the switch is off, > the platform disables the new path by telling CC it's not supported. > > If you read the switch in two different places, then you're allowing a split > brain scenario to occur: > > - The flag is passed, but the app isn't updated (suppose the app doesn't use > CC). This is the case for mojo_shell, ozone_demo. > > - The flag is passed, but the platform isn't updated. No compile error or > anything, but CC drives the platform code in an unsupported way and nothing > works. This is the case for egltest, and soon x11, as well as out of tree > platforms. > > I really don't want a flag that everybody reads, and everything needs to support > immediately, or else weird breakage can happen. Sure, it's easy enough to switch to using ozone's copy, it just means an extra ifdef. Done
On 2014/07/30 20:00:29, achaulk wrote: > On 2014/07/30 19:50:27, spang wrote: > > On 2014/07/30 19:06:23, achaulk wrote: > > > On 2014/07/30 19:03:40, spang wrote: > > > > On 2014/07/30 19:00:13, spang wrote: > > > > > On 2014/07/30 18:50:50, achaulk wrote: > > > > > > Just ozone people for now > > > > > > > > > > I don't think we should use switches as a back channel between the > > > compositor > > > > > and the platform. It's going to be a big headache when other components > > come > > > > in > > > > > ant > > > > > > > > > > This is also likely to cause undefined references in things like the > demo > > > app. > > > > > It doesn't link CC at all. > > > > > > > > > > So I still think you should just put something in the API: > > > > > > > > Doh, I hit send accidently gain. Put something in the API: > > > > > > > > virtual scoped_ptr<SurfacelessOzoneEGL> CreateSurfacelessEGLForWidget( > > > > gfx::AcceleratedWidget widget); > > > > > > > > virtual scoped_ptr<SurfaceOzoneEGL> CreateEGLSurfaceForWidget( > > > > gfx::AcceleratedWidget widget); > > > > > > We still need a way to tell the compositor what is expected to be used > though > > > > There's two good ways to do add a switch that does what you want: > > > > 1. Add it to CC, and implement it by asking the platform for the new path when > > the switch is passed. If it's not passed, or isn't supported, then use the old > > path. > > > > 2. Add it to gbm, and have CC always take then new path when new path is > > supported. If it's not supported, then use the old path. When the switch is > off, > > the platform disables the new path by telling CC it's not supported. > > > > If you read the switch in two different places, then you're allowing a split > > brain scenario to occur: > > > > - The flag is passed, but the app isn't updated (suppose the app doesn't use > > CC). This is the case for mojo_shell, ozone_demo. > > > > - The flag is passed, but the platform isn't updated. No compile error or > > anything, but CC drives the platform code in an unsupported way and nothing > > works. This is the case for egltest, and soon x11, as well as out of tree > > platforms. > > > > I really don't want a flag that everybody reads, and everything needs to > support > > immediately, or else weird breakage can happen. > > Sure, it's easy enough to switch to using ozone's copy, it just means an extra > ifdef. Done What happens when you run ozone_demo with the new flag? I imagine it breaks badly. I get it, so just don't do that. But we're still calling two things with very different semantics the same thing (SurfaceOzoneEGL) and allowing the application to potentially get the wrong kind when the command line is slightly wrong. This is, at best, very surprising to anyone reading the code or trying to run it. So I still think this is pretty bad. And if we land it this way for now then I sure hope we have a plan to fix it. By the way, you need to move the flag back to ui/ozone if you're using it there, to avoid link errors. We don't link the platform against CC.
Sure, I guess it makes sense to add a new thing for this
ping
https://codereview.chromium.org/433543002/diff/40001/ui/ozone/public/surface_... File ui/ozone/public/surface_factory_ozone.h (right): https://codereview.chromium.org/433543002/diff/40001/ui/ozone/public/surface_... ui/ozone/public/surface_factory_ozone.h:96: virtual scoped_ptr<SurfaceOzoneEGL> CreateEmptyEGLSurfaceForWidget( nit: I don't like naming it Empty. Surfaceless is what it is referred to in other parts of the code and how EGL refers to it.
sure
lgtm https://codereview.chromium.org/433543002/diff/60001/ui/ozone/public/surface_... File ui/ozone/public/surface_factory_ozone.cc (right): https://codereview.chromium.org/433543002/diff/60001/ui/ozone/public/surface_... ui/ozone/public/surface_factory_ozone.cc:48: return scoped_ptr<SurfaceOzoneCanvas>(); typo
On 2014/08/07 19:08:17, spang wrote: > lgtm > > https://codereview.chromium.org/433543002/diff/60001/ui/ozone/public/surface_... > File ui/ozone/public/surface_factory_ozone.cc (right): > > https://codereview.chromium.org/433543002/diff/60001/ui/ozone/public/surface_... > ui/ozone/public/surface_factory_ozone.cc:48: return > scoped_ptr<SurfaceOzoneCanvas>(); > typo This is causing a chromeos buildbot failure: http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%2...
On 2014/08/07 21:28:34, stevenjb wrote: > On 2014/08/07 19:08:17, spang wrote: > > lgtm > > > > > https://codereview.chromium.org/433543002/diff/60001/ui/ozone/public/surface_... > > File ui/ozone/public/surface_factory_ozone.cc (right): > > > > > https://codereview.chromium.org/433543002/diff/60001/ui/ozone/public/surface_... > > ui/ozone/public/surface_factory_ozone.cc:48: return > > scoped_ptr<SurfaceOzoneCanvas>(); > > typo > > This is causing a chromeos buildbot failure: > http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%2... Oops, wrong CL... failure cause is https://codereview.chromium.org/445163003
OWNERS review needed +danakj - for content/browser/compositor +kbr - for content/browser/gpu +stevenjb - for chrome/browser/chromeos/login
This patch title seems out of date (and much longer than 72 chars) and it is entirely missing a description. Can you update it?
done
https://codereview.chromium.org/433543002/diff/100001/content/browser/composi... File content/browser/compositor/gpu_process_transport_factory.cc (right): https://codereview.chromium.org/433543002/diff/100001/content/browser/composi... content/browser/compositor/gpu_process_transport_factory.cc:232: return scoped_ptr<cc::OutputSurface>(); // TODO(achaulk) implementation. What's the point of adding this in this CL if it clearly doesn't work?
https://codereview.chromium.org/433543002/diff/100001/content/browser/composi... File content/browser/compositor/gpu_process_transport_factory.cc (right): https://codereview.chromium.org/433543002/diff/100001/content/browser/composi... content/browser/compositor/gpu_process_transport_factory.cc:232: return scoped_ptr<cc::OutputSurface>(); // TODO(achaulk) implementation. On 2014/08/08 15:41:20, danakj wrote: > What's the point of adding this in this CL if it clearly doesn't work? It was mostly to show where/how it would be used, but I could delay this bit until the next CL
https://codereview.chromium.org/433543002/diff/100001/content/browser/composi... File content/browser/compositor/gpu_process_transport_factory.cc (right): https://codereview.chromium.org/433543002/diff/100001/content/browser/composi... content/browser/compositor/gpu_process_transport_factory.cc:232: return scoped_ptr<cc::OutputSurface>(); // TODO(achaulk) implementation. On 2014/08/08 15:46:03, achaulk wrote: > On 2014/08/08 15:41:20, danakj wrote: > > What's the point of adding this in this CL if it clearly doesn't work? > > It was mostly to show where/how it would be used, but I could delay this bit > until the next CL Ya, I think it would make sense to add it once it does something. https://codereview.chromium.org/433543002/diff/100001/content/browser/composi... content/browser/compositor/gpu_process_transport_factory.cc:235: if (!surface) (btw you'd need {} for this cuz multi-line body.)
https://codereview.chromium.org/433543002/diff/100001/content/browser/composi... File content/browser/compositor/gpu_process_transport_factory.cc (right): https://codereview.chromium.org/433543002/diff/100001/content/browser/composi... content/browser/compositor/gpu_process_transport_factory.cc:232: return scoped_ptr<cc::OutputSurface>(); // TODO(achaulk) implementation. On 2014/08/08 15:46:48, danakj wrote: > On 2014/08/08 15:46:03, achaulk wrote: > > On 2014/08/08 15:41:20, danakj wrote: > > > What's the point of adding this in this CL if it clearly doesn't work? > > > > It was mostly to show where/how it would be used, but I could delay this bit > > until the next CL > > Ya, I think it would make sense to add it once it does something. Done.
content/browser/gpu LGTM
The CQ bit was checked by achaulk@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/achaulk@chromium.org/433543002/140001
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: linux_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu/builds/...) mac_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/42389) win_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/win_gpu/builds/47591) android_aosp on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_aosp/bu...) android_chromium_gn_compile_rel on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...) android_clang_dbg on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...) android_dbg on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg/bui...) chromium_presubmit on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...) linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_gn_rel on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_rel_swarming on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) ios_dbg_simulator on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...) ios_rel_device on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device/bu...) ios_rel_device_ninja on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...) mac_chromium_compile_dbg on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_swarming on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...) win8_chromium_rel on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel...) win_chromium_compile_dbg on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...) win_chromium_rel_swarming on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...) win_chromium_x64_rel on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu/builds/...) mac_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/42408) android_chromium_gn_compile_rel on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...) android_clang_dbg on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...) android_dbg on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg/bui...) linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_gn_rel on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) mac_chromium_compile_dbg on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_swarming on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...) win8_chromium_rel on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel...)
The CQ bit was checked by achaulk@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/achaulk@chromium.org/433543002/160001
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: linux_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu/builds/...) mac_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/42459) win_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/win_gpu/builds/47655) android_aosp on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_aosp/bu...) android_chromium_gn_compile_rel on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...) android_clang_dbg on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...) android_dbg on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg/bui...) chromium_presubmit on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...) linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_gn_rel on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_rel_swarming on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) ios_dbg_simulator on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...) ios_rel_device on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device/bu...) ios_rel_device_ninja on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...) mac_chromium_compile_dbg on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_swarming on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...) win8_chromium_rel on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel...) win_chromium_compile_dbg on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...) win_chromium_rel_swarming on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...) win_chromium_x64_rel on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu/builds/...) mac_gpu on tryserver.chromium.gpu (http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/42499) android_chromium_gn_compile_rel on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...) android_clang_dbg on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...) android_dbg on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg/bui...) chromium_presubmit on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...) linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_gn_rel on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_rel_swarming on tryserver.chromium.linux (http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) ios_dbg_simulator on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...) ios_rel_device_ninja on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...) mac_chromium_compile_dbg on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_swarming on tryserver.chromium.mac (http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...) win8_chromium_rel on tryserver.chromium.win (http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel...)
The CQ bit was checked by achaulk@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/achaulk@chromium.org/433543002/180001
Message was sent while issue was closed.
Committed patchset #10 (180001) as 290072 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
