Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2232793002:
services/ui: Move cc::SoftwareOutputDevice implementation into the client lib. (Closed)
|
Created:
4 years, 4 months ago by sadrul Modified:
4 years, 4 months ago CC:
chromium-reviews, jam, sievers+watch_chromium.org, jbauman+watch_chromium.org, darin-cc_chromium.org, kalyank, piman+watch_chromium.org, danakj+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
Descriptionservices/ui: Move cc::SoftwareOutputDevice implementation into the client lib.
Move content::SoftwareOutputDeviceMus into the ui client-lib. Change the code to
create and own a BitmapUploader for the ui::Window, instead of expecting
external code to set it up (NativeWidgetMus used to do this).
Rename the ui::SoftwareOutputDevice. This is more consistent with the other cc
implementations in the client lib (e.g. ui::OutputSurface, ui::ContextProvider
etc.)
This also moves BitmapUploader into the internal API.
BUG=635613
Patch Set 1 #Patch Set 2 : . #
Total comments: 2
Messages
Total messages: 27 (9 generated)
The CQ bit was checked by sadrul@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by sadrul@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== services/ui: Move cc::SoftwareOutputDevice implementation into the client lib. Move content::SoftwareOutputDeviceMus into the ui client-lib. Change the code to create and own a BitmapUploader for the ui::Window, instead of expecting external code to set it up (NativeWidgetMus used to do this). Rename the ui::SoftwareOutputDevice. This is more consistent with the other cc implementations in the client lib (e.g. ui::OutputSurface, ui::ContextProvider etc.) BUG=635613 ========== to ========== services/ui: Move cc::SoftwareOutputDevice implementation into the client lib. Move content::SoftwareOutputDeviceMus into the ui client-lib. Change the code to create and own a BitmapUploader for the ui::Window, instead of expecting external code to set it up (NativeWidgetMus used to do this). Rename the ui::SoftwareOutputDevice. This is more consistent with the other cc implementations in the client lib (e.g. ui::OutputSurface, ui::ContextProvider etc.) This also moves BitmapUploader into the internal API. BUG=635613 ==========
sadrul@chromium.org changed reviewers: + rjkroege@chromium.org, sky@chromium.org
rjkroege@chromium.org: Please review the SoftwareOutputDevice* changes. sky@chromium.org: Please review changes specifically about moving BitmapUploader into the internal API, but exposing the internal API to mus_demo.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
https://codereview.chromium.org/2232793002/diff/20001/services/ui/public/cpp/... File services/ui/public/cpp/BUILD.gn (right): https://codereview.chromium.org/2232793002/diff/20001/services/ui/public/cpp/... services/ui/public/cpp/BUILD.gn:90: "//services/ui/demo:mus_demo_library", Why do we want to move bitmap_uploader to internal, but expose it to the demo? It seems like either we should go with bitmap_uploader be public as we had it, or change mus_demo_library.
https://codereview.chromium.org/2232793002/diff/20001/services/ui/public/cpp/... File services/ui/public/cpp/BUILD.gn (right): https://codereview.chromium.org/2232793002/diff/20001/services/ui/public/cpp/... services/ui/public/cpp/BUILD.gn:90: "//services/ui/demo:mus_demo_library", On 2016/08/10 15:10:39, sky wrote: > Why do we want to move bitmap_uploader to internal, but expose it to the demo? > It seems like either we should go with bitmap_uploader be public as we had it, > or change mus_demo_library. I have been thinking about it myself since I sent it out for review. I think clients should normally use OutputSurface/SoftwareOutputDevice for sending frames to mus, instead of directly using BitmapUploader. mus_demo is a bit of an exception since it exists more as a mus test than as a proper mus client. I feel like having all of OutputSurface, SoftwareOutputDevice, BitmapUploader in the API may be a bit confusing, and it'd be better to restrict the API the clients should use. But maybe it does make sense to allow clients to directly use BitmapUploader too? rjkroege@ what do you think?
On Wed, Aug 10, 2016 at 8:44 AM, <sadrul@chromium.org> wrote: > > https://codereview.chromium.org/2232793002/diff/20001/ > services/ui/public/cpp/BUILD.gn > File services/ui/public/cpp/BUILD.gn (right): > > https://codereview.chromium.org/2232793002/diff/20001/ > services/ui/public/cpp/BUILD.gn#newcode90 > services/ui/public/cpp/BUILD.gn:90: > "//services/ui/demo:mus_demo_library", > On 2016/08/10 15:10:39, sky wrote: > > Why do we want to move bitmap_uploader to internal, but expose it to > the demo? > > It seems like either we should go with bitmap_uploader be public as we > had it, > > or change mus_demo_library. > > I have been thinking about it myself since I sent it out for review. I > think clients should normally use OutputSurface/SoftwareOutputDevice for > sending frames to mus, instead of directly using BitmapUploader. > mus_demo is a bit of an exception since it exists more as a mus test > than as a proper mus client. I feel like having all of OutputSurface, > SoftwareOutputDevice, BitmapUploader in the API may be a bit confusing, > and it'd be better to restrict the API the clients should use. But maybe > it does make sense to allow clients to directly use BitmapUploader too? > Just making sure, but delegating compositors (eg LTHI) should not need a SoftwareOutputDevice. It's a bit hard to tell because "OutputSurface" means multiple things still and I don't know mus well, but wanted to make sure you're not trying to support something unneccesary. > > rjkroege@ what do you think? > > https://codereview.chromium.org/2232793002/ > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
fsamuel@chromium.org changed reviewers: + fsamuel@chromium.org
Drive-by: Given we now do accelerated compositing and this is turned on by default, I propose deleting SoftwareOutputDeviceMus entirely. WDYT?
We don't yet support software compositing in Mus. SoftwareOutputDeviceMus was a hack to get the browser into software compositing mode, and then we uploaded that bitmap into Mus and did accelerated compositing there.
On 2016/08/10 17:11:07, Fady Samuel wrote: > We don't yet support software compositing in Mus. SoftwareOutputDeviceMus was a > hack to get the browser into software compositing mode, and then we uploaded > that bitmap into Mus and did accelerated compositing there. On a linux build (config from crbug.com/635613), making a connection to the gpu-channel fails (haven't looked into why yet). So GpuProcessTransportFactory uses a SoftwareOutputDevice (which is how this thing gets created). What is the alternative to using a SoftwareOutputDevice in this case?
On 2016/08/10 17:16:24, sadrul wrote: > On 2016/08/10 17:11:07, Fady Samuel wrote: > > We don't yet support software compositing in Mus. SoftwareOutputDeviceMus was > a > > hack to get the browser into software compositing mode, and then we uploaded > > that bitmap into Mus and did accelerated compositing there. > > On a linux build (config from crbug.com/635613), making a connection to the > gpu-channel fails (haven't looked into why yet). So GpuProcessTransportFactory > uses a SoftwareOutputDevice (which is how this thing gets created). What is the > alternative to using a SoftwareOutputDevice in this case? We should be doing accelerated compositing. We don't yet support software compositing. That's a fair amount of work that I haven't gotten around to yet.
On Wed, Aug 10, 2016 at 10:16 AM, <sadrul@chromium.org> wrote: > On 2016/08/10 17:11:07, Fady Samuel wrote: > > We don't yet support software compositing in Mus. > SoftwareOutputDeviceMus was > a > > hack to get the browser into software compositing mode, and then we > uploaded > > that bitmap into Mus and did accelerated compositing there. > > On a linux build (config from crbug.com/635613), making a connection to > the > gpu-channel fails (haven't looked into why yet). So > GpuProcessTransportFactory > uses a SoftwareOutputDevice (which is how this thing gets created). What > is the > alternative to using a SoftwareOutputDevice in this case? > Software compositing with non-mus looks like gpu compositing, it's delegated. The output surface just has no ContextProvider on it, so the LTHI produces CompositorFrames with SharedBitmap resources instead of GL textures. > > https://codereview.chromium.org/2232793002/ > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
On 2016/08/10 17:47:53, chromium-reviews wrote: > On Wed, Aug 10, 2016 at 10:16 AM, <mailto:sadrul@chromium.org> wrote: > > > On 2016/08/10 17:11:07, Fady Samuel wrote: > > > We don't yet support software compositing in Mus. > > SoftwareOutputDeviceMus was > > a > > > hack to get the browser into software compositing mode, and then we > > uploaded > > > that bitmap into Mus and did accelerated compositing there. > > > > On a linux build (config from crbug.com/635613), making a connection to > > the > > gpu-channel fails (haven't looked into why yet). So > > GpuProcessTransportFactory > > uses a SoftwareOutputDevice (which is how this thing gets created). What > > is the > > alternative to using a SoftwareOutputDevice in this case? > > > > Software compositing with non-mus looks like gpu compositing, it's > delegated. The output surface just has no ContextProvider on it, so the > LTHI produces CompositorFrames with SharedBitmap resources instead of GL > textures. > > > > > > https://codereview.chromium.org/2232793002/ > > > > -- > You received this message because you are subscribed to the Google Groups > "Chromium-reviews" group. > To unsubscribe from this group and stop receiving emails from it, send an email > to mailto:chromium-reviews+unsubscribe@chromium.org. Yup, the missing piece in Mus is the ability to dispense SharedBitmaps to clients. We don't yet have/use a SharedBitmapManager in Mus.
On 2016/08/10 17:50:23, Fady Samuel wrote: > On 2016/08/10 17:47:53, chromium-reviews wrote: > > On Wed, Aug 10, 2016 at 10:16 AM, <mailto:sadrul@chromium.org> wrote: > > > > > On 2016/08/10 17:11:07, Fady Samuel wrote: > > > > We don't yet support software compositing in Mus. > > > SoftwareOutputDeviceMus was > > > a > > > > hack to get the browser into software compositing mode, and then we > > > uploaded > > > > that bitmap into Mus and did accelerated compositing there. > > > > > > On a linux build (config from crbug.com/635613), making a connection to > > > the > > > gpu-channel fails (haven't looked into why yet). So > > > GpuProcessTransportFactory > > > uses a SoftwareOutputDevice (which is how this thing gets created). What > > > is the > > > alternative to using a SoftwareOutputDevice in this case? > > > > > > > Software compositing with non-mus looks like gpu compositing, it's > > delegated. The output surface just has no ContextProvider on it, so the > > LTHI produces CompositorFrames with SharedBitmap resources instead of GL > > textures. > > > > > > > > > > https://codereview.chromium.org/2232793002/ > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Chromium-reviews" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email > > to mailto:chromium-reviews+unsubscribe@chromium.org. > > Yup, the missing piece in Mus is the ability to dispense SharedBitmaps to > clients. We don't yet have/use a SharedBitmapManager in Mus. Do we still want to have the SoftwareOutputDevice until we have that?
On 2016/08/10 18:04:18, sadrul wrote: > On 2016/08/10 17:50:23, Fady Samuel wrote: > > On 2016/08/10 17:47:53, chromium-reviews wrote: > > > On Wed, Aug 10, 2016 at 10:16 AM, <mailto:sadrul@chromium.org> wrote: > > > > > > > On 2016/08/10 17:11:07, Fady Samuel wrote: > > > > > We don't yet support software compositing in Mus. > > > > SoftwareOutputDeviceMus was > > > > a > > > > > hack to get the browser into software compositing mode, and then we > > > > uploaded > > > > > that bitmap into Mus and did accelerated compositing there. > > > > > > > > On a linux build (config from crbug.com/635613), making a connection to > > > > the > > > > gpu-channel fails (haven't looked into why yet). So > > > > GpuProcessTransportFactory > > > > uses a SoftwareOutputDevice (which is how this thing gets created). What > > > > is the > > > > alternative to using a SoftwareOutputDevice in this case? > > > > > > > > > > Software compositing with non-mus looks like gpu compositing, it's > > > delegated. The output surface just has no ContextProvider on it, so the > > > LTHI produces CompositorFrames with SharedBitmap resources instead of GL > > > textures. > > > > > > > > > > > > > > https://codereview.chromium.org/2232793002/ > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Chromium-reviews" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > email > > > to mailto:chromium-reviews+unsubscribe@chromium.org. > > > > Yup, the missing piece in Mus is the ability to dispense SharedBitmaps to > > clients. We don't yet have/use a SharedBitmapManager in Mus. > > Do we still want to have the SoftwareOutputDevice until we have that? We certainly wouldn't be using it the way it's written in the future. That uses a BitmapUploader which uses gl to upload a texture.
On 2016/08/10 18:06:31, Fady Samuel wrote: > On 2016/08/10 18:04:18, sadrul wrote: > > On 2016/08/10 17:50:23, Fady Samuel wrote: > > > On 2016/08/10 17:47:53, chromium-reviews wrote: > > > > On Wed, Aug 10, 2016 at 10:16 AM, <mailto:sadrul@chromium.org> wrote: > > > > > > > > > On 2016/08/10 17:11:07, Fady Samuel wrote: > > > > > > We don't yet support software compositing in Mus. > > > > > SoftwareOutputDeviceMus was > > > > > a > > > > > > hack to get the browser into software compositing mode, and then we > > > > > uploaded > > > > > > that bitmap into Mus and did accelerated compositing there. > > > > > > > > > > On a linux build (config from crbug.com/635613), making a connection to > > > > > the > > > > > gpu-channel fails (haven't looked into why yet). So > > > > > GpuProcessTransportFactory > > > > > uses a SoftwareOutputDevice (which is how this thing gets created). What > > > > > is the > > > > > alternative to using a SoftwareOutputDevice in this case? > > > > > > > > > > > > > Software compositing with non-mus looks like gpu compositing, it's > > > > delegated. The output surface just has no ContextProvider on it, so the > > > > LTHI produces CompositorFrames with SharedBitmap resources instead of GL > > > > textures. > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2232793002/ > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > > > "Chromium-reviews" group. > > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email > > > > to mailto:chromium-reviews+unsubscribe@chromium.org. > > > > > > Yup, the missing piece in Mus is the ability to dispense SharedBitmaps to > > > clients. We don't yet have/use a SharedBitmapManager in Mus. > > > > Do we still want to have the SoftwareOutputDevice until we have that? > > We certainly wouldn't be using it the way it's written in the future. That uses > a BitmapUploader which uses gl to upload a texture. Right. So it sounds like it'd be better to not expose the BitmapUploader to the external API. But we would still need to provide a SoftwareOutputDevice for now?
On 2016/08/10 18:31:49, sadrul wrote: > On 2016/08/10 18:06:31, Fady Samuel wrote: > > On 2016/08/10 18:04:18, sadrul wrote: > > > On 2016/08/10 17:50:23, Fady Samuel wrote: > > > > On 2016/08/10 17:47:53, chromium-reviews wrote: > > > > > On Wed, Aug 10, 2016 at 10:16 AM, <mailto:sadrul@chromium.org> wrote: > > > > > > > > > > > On 2016/08/10 17:11:07, Fady Samuel wrote: > > > > > > > We don't yet support software compositing in Mus. > > > > > > SoftwareOutputDeviceMus was > > > > > > a > > > > > > > hack to get the browser into software compositing mode, and then we > > > > > > uploaded > > > > > > > that bitmap into Mus and did accelerated compositing there. > > > > > > > > > > > > On a linux build (config from crbug.com/635613), making a connection > to > > > > > > the > > > > > > gpu-channel fails (haven't looked into why yet). So > > > > > > GpuProcessTransportFactory > > > > > > uses a SoftwareOutputDevice (which is how this thing gets created). > What > > > > > > is the > > > > > > alternative to using a SoftwareOutputDevice in this case? > > > > > > > > > > > > > > > > Software compositing with non-mus looks like gpu compositing, it's > > > > > delegated. The output surface just has no ContextProvider on it, so the > > > > > LTHI produces CompositorFrames with SharedBitmap resources instead of GL > > > > > textures. > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2232793002/ > > > > > > > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > Groups > > > > > "Chromium-reviews" group. > > > > > To unsubscribe from this group and stop receiving emails from it, send > an > > > > email > > > > > to mailto:chromium-reviews+unsubscribe@chromium.org. > > > > > > > > Yup, the missing piece in Mus is the ability to dispense SharedBitmaps to > > > > clients. We don't yet have/use a SharedBitmapManager in Mus. > > > > > > Do we still want to have the SoftwareOutputDevice until we have that? > > > > We certainly wouldn't be using it the way it's written in the future. That > uses > > a BitmapUploader which uses gl to upload a texture. > > Right. So it sounds like it'd be better to not expose the BitmapUploader to the > external API. But we would still need to provide a SoftwareOutputDevice for now? I don't see how we're using it now? That seems like a bug. My inclination is to say no, we don't need a SoftwareOutputDevice until we implement software compositing. When we do introduce it, it'll be an implementation detail within Mus, not part of the public API.
On 2016/08/10 18:38:59, Fady Samuel wrote: > On 2016/08/10 18:31:49, sadrul wrote: > > On 2016/08/10 18:06:31, Fady Samuel wrote: > > > On 2016/08/10 18:04:18, sadrul wrote: > > > > On 2016/08/10 17:50:23, Fady Samuel wrote: > > > > > On 2016/08/10 17:47:53, chromium-reviews wrote: > > > > > > On Wed, Aug 10, 2016 at 10:16 AM, <mailto:sadrul@chromium.org> wrote: > > > > > > > > > > > > > On 2016/08/10 17:11:07, Fady Samuel wrote: > > > > > > > > We don't yet support software compositing in Mus. > > > > > > > SoftwareOutputDeviceMus was > > > > > > > a > > > > > > > > hack to get the browser into software compositing mode, and then > we > > > > > > > uploaded > > > > > > > > that bitmap into Mus and did accelerated compositing there. > > > > > > > > > > > > > > On a linux build (config from crbug.com/635613), making a connection > > to > > > > > > > the > > > > > > > gpu-channel fails (haven't looked into why yet). So > > > > > > > GpuProcessTransportFactory > > > > > > > uses a SoftwareOutputDevice (which is how this thing gets created). > > What > > > > > > > is the > > > > > > > alternative to using a SoftwareOutputDevice in this case? > > > > > > > > > > > > > > > > > > > Software compositing with non-mus looks like gpu compositing, it's > > > > > > delegated. The output surface just has no ContextProvider on it, so > the > > > > > > LTHI produces CompositorFrames with SharedBitmap resources instead of > GL > > > > > > textures. > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2232793002/ > > > > > > > > > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > Groups > > > > > > "Chromium-reviews" group. > > > > > > To unsubscribe from this group and stop receiving emails from it, send > > an > > > > > email > > > > > > to mailto:chromium-reviews+unsubscribe@chromium.org. > > > > > > > > > > Yup, the missing piece in Mus is the ability to dispense SharedBitmaps > to > > > > > clients. We don't yet have/use a SharedBitmapManager in Mus. > > > > > > > > Do we still want to have the SoftwareOutputDevice until we have that? > > > > > > We certainly wouldn't be using it the way it's written in the future. That > > uses > > > a BitmapUploader which uses gl to upload a texture. > > > > Right. So it sounds like it'd be better to not expose the BitmapUploader to > the > > external API. But we would still need to provide a SoftwareOutputDevice for > now? > > I don't see how we're using it now? That seems like a bug. My inclination is to > say no, we don't need a SoftwareOutputDevice until we implement software > compositing. When we do introduce it, it'll be an implementation detail within > Mus, not part of the public API. +1. I think it's time that SoftwareOutputDeviceMus went away. (At least in theory) this should now be dead code.
On 2016/08/10 18:41:26, rjkroege wrote: > On 2016/08/10 18:38:59, Fady Samuel wrote: > > On 2016/08/10 18:31:49, sadrul wrote: > > > On 2016/08/10 18:06:31, Fady Samuel wrote: > > > > On 2016/08/10 18:04:18, sadrul wrote: > > > > > On 2016/08/10 17:50:23, Fady Samuel wrote: > > > > > > On 2016/08/10 17:47:53, chromium-reviews wrote: > > > > > > > On Wed, Aug 10, 2016 at 10:16 AM, <mailto:sadrul@chromium.org> > wrote: > > > > > > > > > > > > > > > On 2016/08/10 17:11:07, Fady Samuel wrote: > > > > > > > > > We don't yet support software compositing in Mus. > > > > > > > > SoftwareOutputDeviceMus was > > > > > > > > a > > > > > > > > > hack to get the browser into software compositing mode, and then > > we > > > > > > > > uploaded > > > > > > > > > that bitmap into Mus and did accelerated compositing there. > > > > > > > > > > > > > > > > On a linux build (config from crbug.com/635613), making a > connection > > > to > > > > > > > > the > > > > > > > > gpu-channel fails (haven't looked into why yet). So > > > > > > > > GpuProcessTransportFactory > > > > > > > > uses a SoftwareOutputDevice (which is how this thing gets > created). > > > What > > > > > > > > is the > > > > > > > > alternative to using a SoftwareOutputDevice in this case? > > > > > > > > > > > > > > > > > > > > > > Software compositing with non-mus looks like gpu compositing, it's > > > > > > > delegated. The output surface just has no ContextProvider on it, so > > the > > > > > > > LTHI produces CompositorFrames with SharedBitmap resources instead > of > > GL > > > > > > > textures. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2232793002/ > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > > > "Chromium-reviews" group. > > > > > > > To unsubscribe from this group and stop receiving emails from it, > send > > > an > > > > > > email > > > > > > > to mailto:chromium-reviews+unsubscribe@chromium.org. > > > > > > > > > > > > Yup, the missing piece in Mus is the ability to dispense SharedBitmaps > > to > > > > > > clients. We don't yet have/use a SharedBitmapManager in Mus. > > > > > > > > > > Do we still want to have the SoftwareOutputDevice until we have that? > > > > > > > > We certainly wouldn't be using it the way it's written in the future. That > > > uses > > > > a BitmapUploader which uses gl to upload a texture. > > > > > > Right. So it sounds like it'd be better to not expose the BitmapUploader to > > the > > > external API. But we would still need to provide a SoftwareOutputDevice for > > now? > > > > I don't see how we're using it now? That seems like a bug. My inclination is > to > > say no, we don't need a SoftwareOutputDevice until we implement software > > compositing. When we do introduce it, it'll be an implementation detail within > > Mus, not part of the public API. > > +1. I think it's time that SoftwareOutputDeviceMus went away. (At least in > theory) this > should now be dead code. I think if you delete SoftwareOutputDeviceMus then the only thing using bitmap_uploader is mus_demo so that could be part of mus_demo instead of the client lib. We shouldn't be encouraging the use of bitmap_uploader.
I have put up https://codereview.chromium.org/2247013002/ to remove SODMus.
On 2016/08/11 12:24:49, Fady Samuel wrote: > On 2016/08/10 18:41:26, rjkroege wrote: > > On 2016/08/10 18:38:59, Fady Samuel wrote: > > > On 2016/08/10 18:31:49, sadrul wrote: > > > > On 2016/08/10 18:06:31, Fady Samuel wrote: > > > > > On 2016/08/10 18:04:18, sadrul wrote: > > > > > > On 2016/08/10 17:50:23, Fady Samuel wrote: > > > > > > > On 2016/08/10 17:47:53, chromium-reviews wrote: > > > > > > > > On Wed, Aug 10, 2016 at 10:16 AM, <mailto:sadrul@chromium.org> > > wrote: > > > > > > > > > > > > > > > > > On 2016/08/10 17:11:07, Fady Samuel wrote: > > > > > > > > > > We don't yet support software compositing in Mus. > > > > > > > > > SoftwareOutputDeviceMus was > > > > > > > > > a > > > > > > > > > > hack to get the browser into software compositing mode, and > then > > > we > > > > > > > > > uploaded > > > > > > > > > > that bitmap into Mus and did accelerated compositing there. > > > > > > > > > > > > > > > > > > On a linux build (config from crbug.com/635613), making a > > connection > > > > to > > > > > > > > > the > > > > > > > > > gpu-channel fails (haven't looked into why yet). So > > > > > > > > > GpuProcessTransportFactory > > > > > > > > > uses a SoftwareOutputDevice (which is how this thing gets > > created). > > > > What > > > > > > > > > is the > > > > > > > > > alternative to using a SoftwareOutputDevice in this case? > > > > > > > > > > > > > > > > > > > > > > > > > Software compositing with non-mus looks like gpu compositing, it's > > > > > > > > delegated. The output surface just has no ContextProvider on it, > so > > > the > > > > > > > > LTHI produces CompositorFrames with SharedBitmap resources instead > > of > > > GL > > > > > > > > textures. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/2232793002/ > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > > > > > "Chromium-reviews" group. > > > > > > > > To unsubscribe from this group and stop receiving emails from it, > > send > > > > an > > > > > > > email > > > > > > > > to mailto:chromium-reviews+unsubscribe@chromium.org. > > > > > > > > > > > > > > Yup, the missing piece in Mus is the ability to dispense > SharedBitmaps > > > to > > > > > > > clients. We don't yet have/use a SharedBitmapManager in Mus. > > > > > > > > > > > > Do we still want to have the SoftwareOutputDevice until we have that? > > > > > > > > > > We certainly wouldn't be using it the way it's written in the future. > That > > > > uses > > > > > a BitmapUploader which uses gl to upload a texture. > > > > > > > > Right. So it sounds like it'd be better to not expose the BitmapUploader > to > > > the > > > > external API. But we would still need to provide a SoftwareOutputDevice > for > > > now? > > > > > > I don't see how we're using it now? That seems like a bug. My inclination is > > to > > > say no, we don't need a SoftwareOutputDevice until we implement software > > > compositing. When we do introduce it, it'll be an implementation detail > within > > > Mus, not part of the public API. > > > > +1. I think it's time that SoftwareOutputDeviceMus went away. (At least in > > theory) this > > should now be dead code. > > I think if you delete SoftwareOutputDeviceMus then the only thing using > bitmap_uploader is mus_demo so that could be part of mus_demo instead of the > client lib. We shouldn't be encouraging the use of bitmap_uploader. Doing that in https://codereview.chromium.org/2247023002/ |
