2016-05-04 22:00:13 -07:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
2018-03-23 22:40:04 +09:00
|
|
|
#ifndef widget_windows_WinCompositorWidget_h
|
|
|
|
#define widget_windows_WinCompositorWidget_h
|
2016-05-04 22:00:13 -07:00
|
|
|
|
2016-07-01 01:15:16 -07:00
|
|
|
#include "CompositorWidget.h"
|
2016-07-01 01:15:16 -07:00
|
|
|
#include "gfxASurface.h"
|
2019-10-08 10:07:47 +00:00
|
|
|
#include "mozilla/Atomics.h"
|
2016-05-04 22:00:13 -07:00
|
|
|
#include "mozilla/gfx/CriticalSection.h"
|
2016-07-01 01:15:16 -07:00
|
|
|
#include "mozilla/gfx/Point.h"
|
2019-11-01 11:01:34 +00:00
|
|
|
#include "mozilla/layers/LayersTypes.h"
|
2018-06-21 22:17:48 +02:00
|
|
|
#include "mozilla/Mutex.h"
|
2019-02-07 16:01:41 +09:00
|
|
|
#include "mozilla/widget/WinCompositorWindowThread.h"
|
Bug 1581855:Part 2 - Present VR output to VR Host r=kip,jrmuizel,sotaro,bryce
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
2019-09-26 12:50:44 +00:00
|
|
|
#include "FxROutputHandler.h"
|
2016-07-01 01:15:16 -07:00
|
|
|
#include "nsIWidget.h"
|
2016-05-04 22:00:13 -07:00
|
|
|
|
|
|
|
class nsWindow;
|
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
namespace widget {
|
2016-07-01 01:15:16 -07:00
|
|
|
|
Bug 1373739 - Make headless compositing Windows-compatible, in addition to Linux. r=dvander
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
2017-07-06 17:45:34 -07:00
|
|
|
class PlatformCompositorWidgetDelegate : public CompositorWidgetDelegate {
|
2016-07-01 01:15:16 -07:00
|
|
|
public:
|
|
|
|
// Callbacks for nsWindow.
|
|
|
|
virtual void EnterPresentLock() = 0;
|
|
|
|
virtual void LeavePresentLock() = 0;
|
|
|
|
virtual void OnDestroyWindow() = 0;
|
2020-01-08 18:37:38 +00:00
|
|
|
virtual bool OnWindowResize(const LayoutDeviceIntSize& aSize) = 0;
|
|
|
|
virtual void OnWindowModeChange(nsSizeMode aSizeMode) = 0;
|
2016-07-01 01:15:16 -07:00
|
|
|
|
|
|
|
// Transparency handling.
|
|
|
|
virtual void UpdateTransparency(nsTransparencyMode aMode) = 0;
|
|
|
|
virtual void ClearTransparentWindow() = 0;
|
|
|
|
|
Bug 1373739 - Make headless compositing Windows-compatible, in addition to Linux. r=dvander
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
2017-07-06 17:45:34 -07:00
|
|
|
// CompositorWidgetDelegate Overrides
|
|
|
|
|
|
|
|
PlatformCompositorWidgetDelegate* AsPlatformSpecificDelegate() override {
|
|
|
|
return this;
|
|
|
|
}
|
2016-07-01 01:15:16 -07:00
|
|
|
};
|
Bug 1373739 - Make headless compositing Windows-compatible, in addition to Linux. r=dvander
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
2017-07-06 17:45:34 -07:00
|
|
|
|
|
|
|
class WinCompositorWidgetInitData;
|
|
|
|
|
2016-07-01 01:15:16 -07:00
|
|
|
// This is the Windows-specific implementation of CompositorWidget. For
|
2016-05-04 22:00:13 -07:00
|
|
|
// the most part it only requires an HWND, however it maintains extra state
|
|
|
|
// for transparent windows, as well as for synchronizing WM_SETTEXT messages
|
|
|
|
// with the compositor.
|
2020-01-08 18:36:30 +00:00
|
|
|
class WinCompositorWidget : public CompositorWidget {
|
2016-05-04 22:00:13 -07:00
|
|
|
public:
|
Bug 1373739 - Make headless compositing Windows-compatible, in addition to Linux. r=dvander
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
2017-07-06 17:45:34 -07:00
|
|
|
WinCompositorWidget(const WinCompositorWidgetInitData& aInitData,
|
2017-01-12 17:29:42 -05:00
|
|
|
const layers::CompositorOptions& aOptions);
|
2018-03-29 11:21:47 +09:00
|
|
|
~WinCompositorWidget() override;
|
2016-05-04 22:00:13 -07:00
|
|
|
|
Bug 1373739 - Make headless compositing Windows-compatible, in addition to Linux. r=dvander
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
2017-07-06 17:45:34 -07:00
|
|
|
// CompositorWidget Overrides
|
|
|
|
|
2016-05-04 22:00:14 -07:00
|
|
|
uintptr_t GetWidgetKey() override;
|
2016-07-01 01:15:16 -07:00
|
|
|
WinCompositorWidget* AsWindows() override { return this; }
|
2016-05-04 22:00:14 -07:00
|
|
|
|
2019-02-07 16:01:41 +09:00
|
|
|
HWND GetHwnd() const {
|
|
|
|
return mCompositorWnds.mCompositorWnd ? mCompositorWnds.mCompositorWnd
|
|
|
|
: mWnd;
|
|
|
|
}
|
2016-05-04 22:00:14 -07:00
|
|
|
|
2019-02-07 16:01:41 +09:00
|
|
|
HWND GetCompositorHwnd() const { return mCompositorWnds.mCompositorWnd; }
|
2018-03-29 11:21:47 +09:00
|
|
|
|
|
|
|
void EnsureCompositorWindow();
|
|
|
|
void DestroyCompositorWindow();
|
|
|
|
void UpdateCompositorWndSizeIfNecessary();
|
|
|
|
|
2019-09-04 19:58:51 +00:00
|
|
|
void RequestFxrOutput();
|
Bug 1581855:Part 2 - Present VR output to VR Host r=kip,jrmuizel,sotaro,bryce
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
2019-09-26 12:50:44 +00:00
|
|
|
bool HasFxrOutputHandler() const { return mFxrHandler != nullptr; }
|
|
|
|
FxROutputHandler* GetFxrOutputHandler() const { return mFxrHandler.get(); }
|
2019-09-04 19:58:51 +00:00
|
|
|
|
2020-01-08 18:35:22 +00:00
|
|
|
virtual bool HasGlass() const = 0;
|
2016-05-04 22:00:13 -07:00
|
|
|
|
2020-01-08 18:36:30 +00:00
|
|
|
virtual void UpdateCompositorWnd(const HWND aCompositorWnd,
|
|
|
|
const HWND aParentWnd) = 0;
|
|
|
|
virtual void SetRootLayerTreeID(const layers::LayersId& aRootLayerTreeId) = 0;
|
|
|
|
|
2019-11-01 11:01:34 +00:00
|
|
|
protected:
|
|
|
|
bool mSetParentCompleted;
|
|
|
|
|
2016-05-04 22:00:13 -07:00
|
|
|
private:
|
2016-05-04 22:00:14 -07:00
|
|
|
uintptr_t mWidgetKey;
|
2016-05-04 22:00:13 -07:00
|
|
|
HWND mWnd;
|
2018-03-29 11:21:47 +09:00
|
|
|
|
2019-02-07 16:01:41 +09:00
|
|
|
WinCompositorWnds mCompositorWnds;
|
2018-03-29 11:21:47 +09:00
|
|
|
LayoutDeviceIntSize mLastCompositorWndSize;
|
|
|
|
|
Bug 1581855:Part 2 - Present VR output to VR Host r=kip,jrmuizel,sotaro,bryce
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
2019-09-26 12:50:44 +00:00
|
|
|
UniquePtr<FxROutputHandler> mFxrHandler;
|
2016-05-04 22:00:13 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace widget
|
|
|
|
} // namespace mozilla
|
|
|
|
|
2018-03-23 22:40:04 +09:00
|
|
|
#endif // widget_windows_WinCompositorWidget_h
|