Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2523273002:
Implement Virtual Display class for Android. (Closed)
DescriptionImplement Virtual Display class for Android.
This CL defines a base class for DisplayAndroid, and separates out an implementation for an Android Display backed DisplayAndroidImpl, and a VirtualDisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). Unlike the DisplayAndroidImpl, VirtualDisplayAndroid is mutable to display clients.
The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display.
BUG=643480
Committed: https://crrev.com/0b1a4bdf5be7148ce7c4c9fff464f1592a0a9ea2
Cr-Commit-Position: refs/heads/master@{#434806}
Patch Set 1 #
Total comments: 5
Patch Set 2 : Fix typo #Patch Set 3 : Add missing file #Patch Set 4 : Address comments #
Total comments: 8
Patch Set 5 : Address comments #Patch Set 6 : nit #
Total comments: 4
Patch Set 7 : Address comments #Patch Set 8 : Address feedback #
Total comments: 2
Patch Set 9 : getObservers() to private #
Messages
Total messages: 38 (14 generated)
mthiesse@chromium.org changed reviewers: + boliu@chromium.org
PTAL, I've broken out the necessary DisplayAndroid* changes for the VR virtual display work.
Description was changed from ========== Implement Virtual Display class for Android. BUG=643480 ========== to ========== Implement Virtual Display class for Android. BUG=643480 ==========
+cc some folks
https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... File ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java (right): https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java:12: public class VirtualDisplayAndroid extends DisplayAndroid { Would it be possible to add an 'isVirtual' field to the display so that code that makes assumptions about physical displays (such as the media player creating a surface to output directly to the physical display) could take these new types of displays into account?
https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... File ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java (right): https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java:12: public class VirtualDisplayAndroid extends DisplayAndroid { On 2016/11/23 19:18:09, amp wrote: > Would it be possible to add an 'isVirtual' field to the display so that code > that makes assumptions about physical displays (such as the media player > creating a surface to output directly to the physical display) could take these > new types of displays into account? Preferably, virtual vs. physical displays would be transparent to the rest of the code base. Where does the code live that does this? How is it currently accessing the Display?
https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... File ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java (right): https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java:12: public class VirtualDisplayAndroid extends DisplayAndroid { On 2016/11/23 19:22:23, mthiesse wrote: > On 2016/11/23 19:18:09, amp wrote: > > Would it be possible to add an 'isVirtual' field to the display so that code > > that makes assumptions about physical displays (such as the media player > > creating a surface to output directly to the physical display) could take > these > > new types of displays into account? > > Preferably, virtual vs. physical displays would be transparent to the rest of > the code base. Where does the code live that does this? How is it currently > accessing the Display? I agree that ideally no code would need to know the difference. https://codereview.chromium.org/2439543003/ is my change where I attempt to add a inVR flag (on top of one of your previous patches). It's essentially the same property of if a display is virtual or not. The webmediaplayer_impl doesn't interact with the display directly, but through some interaction with the surface manager (which I don't really understand): https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?sq=pa... If it can be aware that it isn't running on an actual physical display then we can disable the overlay and everything works even in vr mode.
https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... File ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java (right): https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java:12: public class VirtualDisplayAndroid extends DisplayAndroid { On 2016/11/23 19:34:34, amp wrote: > On 2016/11/23 19:22:23, mthiesse wrote: > > On 2016/11/23 19:18:09, amp wrote: > > > Would it be possible to add an 'isVirtual' field to the display so that code > > > that makes assumptions about physical displays (such as the media player > > > creating a surface to output directly to the physical display) could take > > these > > > new types of displays into account? > > > > Preferably, virtual vs. physical displays would be transparent to the rest of > > the code base. Where does the code live that does this? How is it currently > > accessing the Display? > > I agree that ideally no code would need to know the difference. > > https://codereview.chromium.org/2439543003/ is my change where I attempt to add > a inVR flag (on top of one of your previous patches). It's essentially the same > property of if a display is virtual or not. > > The webmediaplayer_impl doesn't interact with the display directly, but through > some interaction with the surface manager (which I don't really understand): > https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?sq=pa... > > If it can be aware that it isn't running on an actual physical display then we > can disable the overlay and everything works even in vr mode. I really don't think we should convey VR-ness or whether or not to use overlays based on a display property. If the media player needs to know if we're in VR, than it needs some other channel through which to pass that information.
https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... File ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java (right): https://codereview.chromium.org/2523273002/diff/1/ui/android/java/src/org/chr... ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java:12: public class VirtualDisplayAndroid extends DisplayAndroid { On 2016/11/23 19:44:51, mthiesse wrote: > On 2016/11/23 19:34:34, amp wrote: > > On 2016/11/23 19:22:23, mthiesse wrote: > > > On 2016/11/23 19:18:09, amp wrote: > > > > Would it be possible to add an 'isVirtual' field to the display so that > code > > > > that makes assumptions about physical displays (such as the media player > > > > creating a surface to output directly to the physical display) could take > > > these > > > > new types of displays into account? > > > > > > Preferably, virtual vs. physical displays would be transparent to the rest > of > > > the code base. Where does the code live that does this? How is it currently > > > accessing the Display? > > > > I agree that ideally no code would need to know the difference. > > > > https://codereview.chromium.org/2439543003/ is my change where I attempt to > add > > a inVR flag (on top of one of your previous patches). It's essentially the > same > > property of if a display is virtual or not. > > > > The webmediaplayer_impl doesn't interact with the display directly, but > through > > some interaction with the surface manager (which I don't really understand): > > > https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?sq=pa... > > > > If it can be aware that it isn't running on an actual physical display then we > > can disable the overlay and everything works even in vr mode. > > I really don't think we should convey VR-ness or whether or not to use overlays > based on a display property. If the media player needs to know if we're in VR, > than it needs some other channel through which to pass that information. I'm interested in other solutions if possible. Anyway I think it's contentious enough that you don't need to worry about it in this change. I'll bring up the discussion again when my change goes out for review.
high level questions: in the current list of stuff in DisplayAndroid, what needs to be controlled? maybe it's not worthwhile to do a whole different impl, if only one or two things. do you have code that makes use of virtualdisplay right now? how will this be integrated into WindowAndroid? presumably you will still need to create a "mostly" real WindowAndroid, except with this display ID? and I think the display id should be generated by display, rather than set by client, probably need to maintain a id -> sdk id map, or the other way around
I do not see DisplayAndroidImpl.java in the list of changes, maybe you need to add it?
On 2016/11/23 22:42:13, Tima Vaisburd wrote: > I do not see DisplayAndroidImpl.java in the list of changes, maybe you need to > add it? Yes sorry, I missed adding it.
On 2016/11/23 21:44:23, boliu_back_dec wrote: > high level questions: > > in the current list of stuff in DisplayAndroid, what needs to be controlled? > maybe it's not worthwhile to do a whole different impl, if only one or two > things. do you have code that makes use of virtualdisplay right now? > > how will this be integrated into WindowAndroid? presumably you will still need > to create a "mostly" real WindowAndroid, except with this display ID? > > and I think the display id should be generated by display, rather than set by > client, probably need to maintain a id -> sdk id map, or the other way around You can see the followup change in Patchset 3 here: https://codereview.chromium.org/2428383006/ The changes to WindowAndroid/VrWindowAndroid are trivial. As for the whole different impl, I started out doing it inside of DisplayAndroid, but realized I was writing two distinct classes in one, so I split it up. Also, we don't want to expose setters for DisplayAndroid properties outside of display/, and having the DisplayAndroid get created/updated by either the DisplayAndroidManger or an arbitrary client was just confusing. I think the split into a mutable VirtualDisplayAndroid and immutable Display backed DisplayAndroidImpl is much cleaner and easier to reason about. I'll move the id generation into display.
write a better CL description please https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... File ui/android/java/src/org/chromium/ui/display/DisplayAndroidImpl.java (right): https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... ui/android/java/src/org/chromium/ui/display/DisplayAndroidImpl.java:20: public class DisplayAndroidImpl extends DisplayAndroid { can class be package visible only? https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... File ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java (right): https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:185: private static final int VIRTUAL_DISPLAY_ID_BEGIN = 1000; I need we need to double check how android generates its display IDs. If it's internally also keeping a counter like this, then 1000 isn't an impossibly high number to reach. But if it's immediately re-using empty slots starting from 0 or something, then it's fine. Can you double check and report back? "Settings->Developer options->Simulate secondary display" should be good enough https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:293: /* package */ int getNextVirtualDisplayId() { nit: maybe generating this ID can happen in addVirtualDisplay, then one less back and forth call, and can also assert the generated id isn't already in the map also can we crash hard if the IDs ever collide, in both ways? if this is buggy, we want to know immediately https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:298: mIdMap.put(display.getDisplayId(), display); should this immediately create the native side display? or maybe createVirtualDisplay should take all the params, so it's impossible for client to leave things in an inconsistent state
Patchset #5 (id:80001) has been deleted
Description was changed from ========== Implement Virtual Display class for Android. BUG=643480 ========== to ========== Implement Virtual Display class for Android. This CL defines a base class for DisplayAndroid, and separates out a separate implementation for an Android Display backed DisplayAndroid, and a Virtual DisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display. BUG=643480 ==========
Description was changed from ========== Implement Virtual Display class for Android. This CL defines a base class for DisplayAndroid, and separates out a separate implementation for an Android Display backed DisplayAndroid, and a Virtual DisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display. BUG=643480 ========== to ========== Implement Virtual Display class for Android. This CL defines a base class for DisplayAndroid, and separates out an implementation for an Android Display backed DisplayAndroid, and a Virtual DisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display. BUG=643480 ==========
Description was changed from ========== Implement Virtual Display class for Android. This CL defines a base class for DisplayAndroid, and separates out an implementation for an Android Display backed DisplayAndroid, and a Virtual DisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display. BUG=643480 ========== to ========== Implement Virtual Display class for Android. This CL defines a base class for DisplayAndroid, and separates out an implementation for an Android Display backed DisplayAndroidImpl, and a VirtualDisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). Unlike the DisplayAndroidImpl, VirtualDisplayAndroid is mutable to display clients. The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display. BUG=643480 ==========
https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... File ui/android/java/src/org/chromium/ui/display/DisplayAndroidImpl.java (right): https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... ui/android/java/src/org/chromium/ui/display/DisplayAndroidImpl.java:20: public class DisplayAndroidImpl extends DisplayAndroid { On 2016/11/28 15:53:31, boliu_back_dec wrote: > can class be package visible only? Done. https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... File ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java (right): https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:185: private static final int VIRTUAL_DISPLAY_ID_BEGIN = 1000; On 2016/11/28 15:53:31, boliu_back_dec wrote: > I need we need to double check how android generates its display IDs. > > If it's internally also keeping a counter like this, then 1000 isn't an > impossibly high number to reach. But if it's immediately re-using empty slots > starting from 0 or something, then it's fine. > > Can you double check and report back? "Settings->Developer options->Simulate > secondary display" should be good enough Android effectively does what I'm doing here, but starts at 1. They never re-use slots, and both virtual and physical displays are assigned IDs in the same way - search for "assignDisplayIdLocked" in android source to verify. This is true for at least as far back as jellybean. I'll up it to something more impossibly high. https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:293: /* package */ int getNextVirtualDisplayId() { On 2016/11/28 15:53:31, boliu_back_dec wrote: > nit: maybe generating this ID can happen in addVirtualDisplay, then one less > back and forth call, and can also assert the generated id isn't already in the > map > > also can we crash hard if the IDs ever collide, in both ways? if this is buggy, > we want to know immediately Done. https://codereview.chromium.org/2523273002/diff/60001/ui/android/java/src/org... ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:298: mIdMap.put(display.getDisplayId(), display); On 2016/11/28 15:53:31, boliu_back_dec wrote: > should this immediately create the native side display? or maybe > createVirtualDisplay should take all the params, so it's impossible for client > to leave things in an inconsistent state Done.
mthiesse@chromium.org changed reviewers: + tedchoc@chromium.org
+tedchoc@chromium.org for BUILD.gn and WindowAndroid.java OWNERS.
https://codereview.chromium.org/2523273002/diff/120001/ui/android/java/src/or... File ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java (right): https://codereview.chromium.org/2523273002/diff/120001/ui/android/java/src/or... ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:295: /* package */ int getNextVirtualDisplayId() { private https://codereview.chromium.org/2523273002/diff/120001/ui/android/java/src/or... File ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java (right): https://codereview.chromium.org/2523273002/diff/120001/ui/android/java/src/or... ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java:61: for (DisplayAndroidObserver o : observers) { this code doesn't support observer removing itself inside an observer call eg if observer removes self in onDIPScaleChanged, then it's not expecting to get onRotationChanged basically this should match the code in DisplayAndroidImpl, yes it does make an additional copy, but doubt that's an actual perf issue sorry didn't notice this last time..
Patchset #7 (id:140001) has been deleted
https://codereview.chromium.org/2523273002/diff/120001/ui/android/java/src/or... File ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java (right): https://codereview.chromium.org/2523273002/diff/120001/ui/android/java/src/or... ui/android/java/src/org/chromium/ui/display/DisplayAndroidManager.java:295: /* package */ int getNextVirtualDisplayId() { On 2016/11/28 19:33:15, boliu_back_dec wrote: > private Done. https://codereview.chromium.org/2523273002/diff/120001/ui/android/java/src/or... File ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java (right): https://codereview.chromium.org/2523273002/diff/120001/ui/android/java/src/or... ui/android/java/src/org/chromium/ui/display/VirtualDisplayAndroid.java:61: for (DisplayAndroidObserver o : observers) { On 2016/11/28 19:33:15, boliu_back_dec wrote: > this code doesn't support observer removing itself inside an observer call > > eg if observer removes self in onDIPScaleChanged, then it's not expecting to get > onRotationChanged > > basically this should match the code in DisplayAndroidImpl, yes it does make an > additional copy, but doubt that's an actual perf issue > > sorry didn't notice this last time.. Good point.
lgtm
On 2016/11/24 18:59:39, mthiesse wrote: > On 2016/11/23 21:44:23, boliu_back_dec wrote: > > high level questions: > > > > in the current list of stuff in DisplayAndroid, what needs to be controlled? > > maybe it's not worthwhile to do a whole different impl, if only one or two > > things. do you have code that makes use of virtualdisplay right now? > > > > how will this be integrated into WindowAndroid? presumably you will still need > > to create a "mostly" real WindowAndroid, except with this display ID? > > > > and I think the display id should be generated by display, rather than set by > > client, probably need to maintain a id -> sdk id map, or the other way around > > You can see the followup change in Patchset 3 here: > https://codereview.chromium.org/2428383006/ > The changes to WindowAndroid/VrWindowAndroid are trivial. > As for the whole different impl, I started out doing it inside of > DisplayAndroid, but realized I was writing two distinct classes in one, so I > split it up. Also, we don't want to expose setters for DisplayAndroid properties > outside of display/, and having the DisplayAndroid get created/updated by either > the DisplayAndroidManger or an arbitrary client was just confusing. I think the > split into a mutable VirtualDisplayAndroid and immutable Display backed > DisplayAndroidImpl is much cleaner and easier to reason about. > > I'll move the id generation into display. I'll say that I was confused by this as well. In my mind, I think it would be cleaner if there was a base class DisplayAndroid that had all the member variables (also is the one that will notify observers on changes). Then, the base class exposes one protected method update(...) that takes in all the necessary info (not the Display from android itself). Then DisplayAndroidImpl would have a single method updateFromDisplay(Display display) that pulls out the necessary bits and calls update on the base class. Although I wonder if PhysicalDisplayAndroid or something might be clearer there too since it is odd to me that Impl isn't clearly a descriptor for a display tied to a physical one where VirtualDisplayAndroid is much clearer IMO. Then the virtual display only has the update methods and removes the need for duplicate member variables and getters. I think the update method visibility should be the same between this proposal and what you'll end up doing with this patch, but I think it cuts down on the boilerplate between the two.
Patchset #8 (id:170001) has been deleted
On 2016/11/28 21:14:58, Ted C wrote: > On 2016/11/24 18:59:39, mthiesse wrote: > > On 2016/11/23 21:44:23, boliu_back_dec wrote: > > > high level questions: > > > > > > in the current list of stuff in DisplayAndroid, what needs to be controlled? > > > maybe it's not worthwhile to do a whole different impl, if only one or two > > > things. do you have code that makes use of virtualdisplay right now? > > > > > > how will this be integrated into WindowAndroid? presumably you will still > need > > > to create a "mostly" real WindowAndroid, except with this display ID? > > > > > > and I think the display id should be generated by display, rather than set > by > > > client, probably need to maintain a id -> sdk id map, or the other way > around > > > > You can see the followup change in Patchset 3 here: > > https://codereview.chromium.org/2428383006/ > > The changes to WindowAndroid/VrWindowAndroid are trivial. > > As for the whole different impl, I started out doing it inside of > > DisplayAndroid, but realized I was writing two distinct classes in one, so I > > split it up. Also, we don't want to expose setters for DisplayAndroid > properties > > outside of display/, and having the DisplayAndroid get created/updated by > either > > the DisplayAndroidManger or an arbitrary client was just confusing. I think > the > > split into a mutable VirtualDisplayAndroid and immutable Display backed > > DisplayAndroidImpl is much cleaner and easier to reason about. > > > > I'll move the id generation into display. > > I'll say that I was confused by this as well. > > In my mind, I think it would be cleaner if there was a base class > DisplayAndroid that had all the member variables (also is the one > that will notify observers on changes). Then, the base class > exposes one protected method update(...) that takes in all the > necessary info (not the Display from android itself). > > Then DisplayAndroidImpl would have a single method > updateFromDisplay(Display display) that pulls out the necessary bits > and calls update on the base class. > > Although I wonder if PhysicalDisplayAndroid or something might be > clearer there too since it is odd to me that Impl isn't clearly a > descriptor for a display tied to a physical one where > VirtualDisplayAndroid is much clearer IMO. > > Then the virtual display only has the update methods and removes the > need for duplicate member variables and getters. > > I think the update method visibility should be the same between this > proposal and what you'll end up doing with this patch, but I think > it cuts down on the boilerplate between the two. Totally agree, thanks for the feedback. PTAL
lgtm https://codereview.chromium.org/2523273002/diff/190001/ui/android/java/src/or... File ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java (right): https://codereview.chromium.org/2523273002/diff/190001/ui/android/java/src/or... ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:201: protected DisplayAndroidObserver[] getObservers() { can this be private again?
https://codereview.chromium.org/2523273002/diff/190001/ui/android/java/src/or... File ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java (right): https://codereview.chromium.org/2523273002/diff/190001/ui/android/java/src/or... ui/android/java/src/org/chromium/ui/display/DisplayAndroid.java:201: protected DisplayAndroidObserver[] getObservers() { On 2016/11/28 22:38:43, Ted C wrote: > can this be private again? Done.
The CQ bit was checked by mthiesse@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from boliu@chromium.org, tedchoc@chromium.org Link to the patchset: https://codereview.chromium.org/2523273002/#ps210001 (title: "getObservers() to private")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 210001, "attempt_start_ts": 1480372886156290,
"parent_rev": "201a49021117fe933639cc6ef32598d5a11d1200", "commit_rev":
"23c9495fb1b315f1d4eda44d8dbd49f198c972ab"}
Message was sent while issue was closed.
Description was changed from ========== Implement Virtual Display class for Android. This CL defines a base class for DisplayAndroid, and separates out an implementation for an Android Display backed DisplayAndroidImpl, and a VirtualDisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). Unlike the DisplayAndroidImpl, VirtualDisplayAndroid is mutable to display clients. The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display. BUG=643480 ========== to ========== Implement Virtual Display class for Android. This CL defines a base class for DisplayAndroid, and separates out an implementation for an Android Display backed DisplayAndroidImpl, and a VirtualDisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). Unlike the DisplayAndroidImpl, VirtualDisplayAndroid is mutable to display clients. The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display. BUG=643480 ==========
Message was sent while issue was closed.
Committed patchset #9 (id:210001)
Message was sent while issue was closed.
Description was changed from ========== Implement Virtual Display class for Android. This CL defines a base class for DisplayAndroid, and separates out an implementation for an Android Display backed DisplayAndroidImpl, and a VirtualDisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). Unlike the DisplayAndroidImpl, VirtualDisplayAndroid is mutable to display clients. The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display. BUG=643480 ========== to ========== Implement Virtual Display class for Android. This CL defines a base class for DisplayAndroid, and separates out an implementation for an Android Display backed DisplayAndroidImpl, and a VirtualDisplayAndroid (currently intended for use by Chrome's VRShell and WebVR). Unlike the DisplayAndroidImpl, VirtualDisplayAndroid is mutable to display clients. The display ID for a DisplayAndroid can no longer be assumed to match that of an Android Display. BUG=643480 Committed: https://crrev.com/0b1a4bdf5be7148ce7c4c9fff464f1592a0a9ea2 Cr-Commit-Position: refs/heads/master@{#434806} ==========
Message was sent while issue was closed.
Patchset 9 (id:??) landed as https://crrev.com/0b1a4bdf5be7148ce7c4c9fff464f1592a0a9ea2 Cr-Commit-Position: refs/heads/master@{#434806} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
