Closed Bug 1497606 Opened Last year Closed 11 months ago
_composition _ in screen _capturer _win _gdi
47 bytes, text/x-phabricator-request
|Details | Review|
We have a few changes to control composition being disabled: https://searchfox.org/mozilla-central/search?q=disable_composition_&redirect=false We should upstream those.
It appears that disable_composition_ is always set to false  and so these changes can be removed.  https://searchfox.org/mozilla-central/rev/3fdc51e66c9487b39220ad58dcee275fca070ccd/dom/media/systemservices/video_engine/desktop_capture_impl.cc#347
Assignee: nobody → dminor
Status: NEW → ASSIGNED
Summary: Upstream disable_composition_ in screen_capturer_win_gdi → Remove disable_composition_ in screen_capturer_win_gdi
Now that I look at this again, it appears we added disable_composition_ to store the value of the option. I don't see why we can't just use whether or not composition_func_ has a value to track whether we've disabled composition which is what upstream does.
This removes disable_composition_ and instead uses the value of composition_func_ to determine whether or not composition is disabled. This is what is done by upstream webrtc.org. We call options.set_disable_effects(false) in desktop_capture_impl.cc.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/b3f5cca4be44 Remove disable_composition_ in screen_capturer_win_gdi; r=ng
You need to log in before you can comment on or make changes to this bug.