This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
If VR process haven't launched yet, we couldn't get available VR displays and its states, so we need to make enumationCompleted to be false, and ask it do the enumeration again.
Differential Revision: https://phabricator.services.mozilla.com/D46238
--HG--
extra : moz-landing-system : lando
This change introduces the HTML-based UI for the 2D Content window in Firefox
Reality for Desktop, accessed via the --fxr command line parameter.
Differential Revision: https://phabricator.services.mozilla.com/D42546
--HG--
extra : moz-landing-system : lando
This change introduces plumbing for communicating with the GPU process through
VRShMem while bootstrapping Firefox for creating a window with Firefox Reality.
Test impact shows a fabricated value returned for the texture handle in VRShMem.
Differential Revision: https://phabricator.services.mozilla.com/D41383
--HG--
extra : moz-landing-system : lando
This change introduces the HTML-based UI for the 2D Content window in Firefox
Reality for Desktop, accessed via the --fxr command line parameter.
Differential Revision: https://phabricator.services.mozilla.com/D42546
--HG--
extra : moz-landing-system : lando
This changes the way crash reports for child processes happening too early
during the child process' startup. Before bug 1547698 we wrote a partial
.extra file with those crashes that lacked the process type. The user would
not be notified of those crashes until she restarted Firefox and even when
submitted those crashes would be erroneously labeled as browser crashes.
After bug 1547698 we stopped writing .extra files entirely for those crashes
which left orphaned .dmp files among the pending crash reports.
This patch does three things to improve the situation:
* It writes a partial .extra file so that the crashes are detected at the next
startup. So the user is still not notified directly of these crashes but she
can report them later.
* It adds the process type to the .extra file so that the crash reporters are
labelled correctly.
* It fixes a leak in the `pidToMinidump` hash-map. Since the crashes were
not finalized the `ChildProcessData` strucutre associated with them would
never be fred.
Differential Revision: https://phabricator.services.mozilla.com/D40810
--HG--
extra : moz-landing-system : lando
This change adds a new export, SendUIMessageToVRWindow, from vrhost.dll
that allows the caller to forward a subset of UI messages to the VR
window in Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D40828
--HG--
extra : moz-landing-system : lando
Functions available only in Nightlies should not be exported outside of Nightly
builds. This change splits the exports into 2 def files (since the preprocessor
is not available for def file).
Differential Revision: https://phabricator.services.mozilla.com/D40653
--HG--
extra : moz-landing-system : lando
Bug 1570440 - [Web content] Firefox Crashes on CNN.COM (Windows7)
This change addresses an issue where VRShMem can be in an invalid state when
there is no VR process available. In this case, the VRExternalShmem struct is
allocated on the heap rather than accessed via shared memory. When VRService
stops, it clears this pointer, but cannot re-access it when it restarts. Thus,
this results in a nullptr crash when a tab Enters, Exits, and Re-enters VR.
The fix is to distinguish between in-proc heap allocation vs cross-proc shared
memory so that VRService can decide to make the call to LeaveShMem in its Stop
function. This will keep the heap allocation alive across service restarts and
prevent the null crash.
Differential Revision: https://phabricator.services.mozilla.com/D40681
--HG--
extra : moz-landing-system : lando
In order to support multiple API's (WebVR + WebXR) being enabled simultaneously, a new class, gfx::VRManagerEventObserver, implements a pure virtual interface to be shared by both the WebVR and WebXR observers of XR device related events.
Differential Revision: https://phabricator.services.mozilla.com/D39985
--HG--
extra : moz-landing-system : lando
Bug 1570440 - [Web content] Firefox Crashes on CNN.COM (Windows7)
This change addresses an issue where VRShMem can be in an invalid state when
there is no VR process available. In this case, the VRExternalShmem struct is
allocated on the heap rather than accessed via shared memory. When VRService
stops, it clears this pointer, but cannot re-access it when it restarts. Thus,
this results in a nullptr crash when a tab Enters, Exits, and Re-enters VR.
The fix is to distinguish between in-proc heap allocation vs cross-proc shared
memory so that VRService can decide to make the call to LeaveShMem in its Stop
function. This will keep the heap allocation alive across service restarts and
prevent the null crash.
Differential Revision: https://phabricator.services.mozilla.com/D40681
--HG--
extra : moz-landing-system : lando
This change creates the new export CreateVRWindow from vrhost.dll. This API
results in spawning a new Firefox window with the Firefox Reality 2D UI and
returns data needed for the host to interact with it. VRShMem is used to pass
data across process boundaries during this bootstrap process.
Additional tests are added to vrhost to be later converted to unittests.
Differential Revision: https://phabricator.services.mozilla.com/D40236
--HG--
rename : gfx/vr/vrhost/vrhost.cpp => gfx/vr/vrhost/vrhosttest.cpp
extra : moz-landing-system : lando
In order to support the WebXR implementation, VRDisplayState is being extended to enumerate the type of sessions a device supports (Inline, Immersive-VR, or Immersive-AR) and to report if the blend mode for AR would be additive or alpha blended).
Differential Revision: https://phabricator.services.mozilla.com/D39916
--HG--
extra : moz-landing-system : lando
Call VRManager::StartFrame directly instead of using a PostTask on Android.
Differential Revision: https://phabricator.services.mozilla.com/D39691
--HG--
extra : moz-landing-system : lando
This change adds functionality for the new command line argument, --fxr. This
will be used to create a new, separate browser window for Firefox Reality on
desktop.
Differential Revision: https://phabricator.services.mozilla.com/D37957
--HG--
extra : moz-landing-system : lando
This change replaces and removes code in VRManager that was refactored into the
new VRShMem class.
Differential Revision: https://phabricator.services.mozilla.com/D36986
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This change adds functionality for the new command line argument, --fxr. This
will be used to create a new, separate browser window for Firefox Reality on
desktop.
Differential Revision: https://phabricator.services.mozilla.com/D37957
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
This change replaces and removes code in VRManager that was refactored into the
new VRShMem class.
Differential Revision: https://phabricator.services.mozilla.com/D36986
--HG--
extra : moz-landing-system : lando
This change replaces and removes code in VRManager that was refactored into the
new VRShMem class.
Differential Revision: https://phabricator.services.mozilla.com/D36986
--HG--
extra : moz-landing-system : lando
This change introduces the stubs for nsFxrCommandLineHandler,
which will support launching Firefox Reality on Desktop.
Differential Revision: https://phabricator.services.mozilla.com/D37760
--HG--
extra : moz-landing-system : lando
This change brings the related ShMem code from VRManager and VRService into a
new class, VRShMem. This is to support future work where this ShMem will be used
for other efforts. Having this code in the same class will enable it to be more
easily shared in these efforts.
Until the new class replaces the code in VRManager and VRService, it can be
exercised and validated with two instances of vrtesthost, with the -testmgr and
-testsvc parameters.
Differential Revision: https://phabricator.services.mozilla.com/D36649
--HG--
extra : moz-landing-system : lando
gfxVRPuppet will be replaced with a fully asynchronous puppet automation that runs in the VR process.
Differential Revision: https://phabricator.services.mozilla.com/D26263
--HG--
extra : moz-landing-system : lando
The patch also removes the dom.vr.oculus.quit.timeout pref, because it's
unused.
Differential Revision: https://phabricator.services.mozilla.com/D35973
--HG--
extra : rebase_source : bd16ed5ff0b7c2b4f8e653e9835610b25b14a39f
Remove unecessary Unregister method.
The method is called only once and right prior the parent object gets deleted.
There could be a case where the VRProcessManager destructor gets called before xpcom's shutdown. This would have lead to the now deleted object being called by the Preferences.
Differential Revision: https://phabricator.services.mozilla.com//D32688
--HG--
extra : amend_source : 20b8b4740030ab141856d753a3801b55d607eea3
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This change introduces a new dll, vrhost, to make it easier to share
VR code across multiple process.
An executable, vrtesthost, is also added for testing purposes to
validate the DLL loads in a minimal environment.
Differential Revision: https://phabricator.services.mozilla.com/D30653
--HG--
extra : moz-landing-system : lando
This change introduces a new dll, vrhost, to make it easier to share
VR code across multiple process.
An executable, vrtesthost, is also added for testing purposes to
validate the DLL loads in a minimal environment.
Differential Revision: https://phabricator.services.mozilla.com/D30653
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
It would have been nicer and more logical to use a MacIOSurfaceImage to store the colorspace information, however the data passed around is a IOSurface Id via a SurfaceDescriptorMacIOSurface; the original data structure isn't kept; so we must transit the data at the same time as the IOSurface Id.
Also remove unnecessary test (new operator is infallible).
Differential Revision: https://phabricator.services.mozilla.com/D26058
--HG--
extra : moz-landing-system : lando
When the compositor thread has begun shutdown, it will spin the event
loop for the main thread until the last CompositorThreadHolder reference
has been released. While spinning, new IPDL objects may be attempted to
be created which depend on the compositor thread; we should check to
ensure the compositor thread is still around before proceeding with
creation. These objects include CompositorManagerParent,
ImageBridgeParent, and VRManagerParent. Additionally there is a very
similar bug between the vsync thread and VsyncBridgeChild.
Differential Revision: https://phabricator.services.mozilla.com/D23308
Moved non-POD member of VRDisplayInfo to VRDisplayHost
VRDisplayInfo is now also a POD type (And asserted so)
Use PlainOldDataSerializer for POD types in VRMessageUtils
Moved non-POD member of VRDisplayInfo to VRDisplayHost
VRDisplayInfo is now also a POD type (And asserted so)
Differential Revision: https://phabricator.services.mozilla.com/D24577
--HG--
extra : moz-landing-system : lando
WebVR will not initialize correctly (VR process will not be started and the headset data is frozen) for subsequent sessions in a new tab once the VR process has been shut down due to being idle.
Differential Revision: https://phabricator.services.mozilla.com/D23027
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
In order to enable asynchronous launch, destruction of
GeckoChildProcessHost (and its subclasses) has to be delayed until after
launching (or anything else that might be made asynchronous in the
future) has completed, to prevent use-after-free. However, there are
other dependencies on process hosts always being destroyed on the I/O
thread, so refcounting would be difficult to use.
Instead, GeckoChildProcessHost now may not be destroyed directly, but
must go through a method that handles the scheduling.
There are also some minor cleanups to the affected headers (removed
duplicate access modifiers, and made PluginProcessParent final).
Depends on D18010
Differential Revision: https://phabricator.services.mozilla.com/D18011
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
This change updates the structs VRDisplayState, VRLayer_2D_Content, and VRLayer_Stereo_Immersive to not have 'm' prefix for its members.
Differential Revision: https://phabricator.services.mozilla.com/D16000
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This change fixes a compiler warning, where a VRSensorState object is returned on the stack as a rather large object.
To address this warning, the return type of VRDisplayExternal::GetSensorState now returns a const reference to the member. The rest of the change are updates to uphold the new constness.
Differential Revision: https://phabricator.services.mozilla.com/D13586
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
By default, windows.h exposes a large number of problematic define statements
which are UpperCamelCase, such as a define from `CreateWindow` to
`CreateWindow{A,W}`.
As many of these names are generic (e.g. CreateFile, CreateWindow), they can
mess up Gecko code that may legitimately have its own methods with the same
names.
The header also defines some traditional SCREAMING_SNAKE_CASE defines which
can mess up our code by conflicting with local values.
This patch adds a simple code generator which generates wrappers for these
defines, and uses them to wrap the windows.h wrapper using the `stl_wrappers`
mechanism, allowing us to use windows.h in more places.
Differential Revision: https://phabricator.services.mozilla.com/D10932
By default, windows.h exposes a large number of problematic define statements
which are UpperCamelCase, such as a define from `CreateWindow` to
`CreateWindow{A,W}`.
As many of these names are generic (e.g. CreateFile, CreateWindow), they can
mess up Gecko code that may legitimately have its own methods with the same
names.
The header also defines some traditional SCREAMING_SNAKE_CASE defines which
can mess up our code by conflicting with local values.
This patch adds a simple code generator which generates wrappers for these
defines, and uses them to wrap the windows.h wrapper using the `stl_wrappers`
mechanism, allowing us to use windows.h in more places.
Differential Revision: https://phabricator.services.mozilla.com/D10932
We are refactoring much of the code in gfx/vr, moving
most of the code that runs in the VRListenerThread into
it's own process. The remaining code will be non-blocking
once this refactoring is complete.
In order to resolve some shutdown crashes, it is simpler
to remove the VRListenerThread and the related code
starting and stopping this thread. If this is done
prior to completion of the refactoring for Bug 1473399
(Enable VRService thread by default), there would be a
regression in responsiveness during detection of VR
hardware due to blocking API calls moving off the thread.
Differential Revision: https://phabricator.services.mozilla.com/D7227
--HG--
extra : moz-landing-system : lando
During shutdown, VRManager::RunTasks may be run outside
of the VR Listener thread due to residual nsTimer events.
This results in intermittent assertions during shutdown
when the assert is hit.
We do not need to run these periodic tasks during shutdown
so we can simply early-exit here.
Differential Revision: https://phabricator.services.mozilla.com/D7022
--HG--
extra : moz-landing-system : lando
- Implemented 1ms, 10ms, and 100ms VR tasks, dispatched from
VRManager
- Removed Android-specific code that compensated for
tasks that did not run when the...
...compositor was paused.
Differential Revision: https://phabricator.services.mozilla.com/D3378
--HG--
extra : moz-landing-system : lando
* Avoid writing past an XPCOM string's length using BeginWriting().
* Instead of having a constant for max path length, query the
Windows API for the length it wants.
* Avoid using AppendPrintf for mere concatenation using arguments
that might contain non-ASCII.
MozReview-Commit-ID: 9m7xOHRTB35
Differential Revision: https://phabricator.services.mozilla.com/D5349
--HG--
extra : moz-landing-system : lando
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--HG--
extra : moz-landing-system : lando
The WebVR api was returning a headset pose predicted one additional frame in the
future, but the SteamVR async reprojection was reprojecting it using the
prior (correct) frame's pose.
This resulted in a sickness inducing swimming effect as well as deregistration
from the Vive chaperone bounds.
Differential Revision: https://phabricator.services.mozilla.com/D2693
--HG--
extra : moz-landing-system : lando
- Refactored gfxVROpenVR to use gfxVRExternal interface from the
VR Service. Existing gfxVROpenVR left in place (for now) to
allow VR service to be enabled or disabled by pref.
- The VR service, containing gfxVROpenVR, is to run in-process within
its own thread first, then to be later moved to its own process.
- Fixed periodic immersive mode flicker that occured due to HMD pose and
HMD state being separately sampled from the Shmem. It was possible
to advance a frame without also getting an updated pose if a dirty
copy of the shmem was detected.
MozReview-Commit-ID: IvpJErmi5kF
--HG--
extra : rebase_source : 0e21d3414a13dc514c3035f2bd5f6adc365b465d
- The VR External interface/shmem and gfxVRExternal are
updated to enable entering VR, exiting VR, and submitting
frames.
- You can now construct gfxVRExternal using a pointer to
the VR External API shmem, if it is created elsewhere.
MozReview-Commit-ID: LZuoLvoEmKO
--HG--
extra : rebase_source : ab38ae4c34f9ac5cdd69e7222f12b1c758307057