2016-05-05 08:00:13 +03: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/. */
|
|
|
|
|
2016-07-01 11:15:16 +03:00
|
|
|
#include "WinCompositorWidget.h"
|
2019-05-26 17:31:53 +03:00
|
|
|
|
2019-07-26 04:10:23 +03:00
|
|
|
#include "mozilla/StaticPrefs_layers.h"
|
2016-08-24 01:18:55 +03:00
|
|
|
#include "mozilla/gfx/DeviceManagerDx.h"
|
2016-05-05 08:00:14 +03:00
|
|
|
#include "mozilla/gfx/Point.h"
|
2016-08-24 01:18:55 +03:00
|
|
|
#include "mozilla/layers/Compositor.h"
|
2019-10-08 13:07:47 +03:00
|
|
|
#include "mozilla/layers/CompositorThread.h"
|
|
|
|
#include "mozilla/webrender/RenderThread.h"
|
2016-07-01 11:15:16 +03:00
|
|
|
#include "mozilla/widget/PlatformWidgetTypes.h"
|
2016-07-19 21:56:07 +03:00
|
|
|
#include "nsWindow.h"
|
|
|
|
#include "VsyncDispatcher.h"
|
2018-03-29 05:21:47 +03:00
|
|
|
#include "WinCompositorWindowThread.h"
|
2019-09-04 22:58:51 +03:00
|
|
|
#include "VRShMem.h"
|
2016-05-05 08:00:13 +03:00
|
|
|
|
2016-08-24 01:18:55 +03:00
|
|
|
#include <ddraw.h>
|
|
|
|
|
2016-05-05 08:00:13 +03:00
|
|
|
namespace mozilla {
|
|
|
|
namespace widget {
|
|
|
|
|
2016-05-05 08:00:14 +03:00
|
|
|
using namespace mozilla::gfx;
|
2018-06-21 23:17:48 +03:00
|
|
|
using namespace mozilla;
|
2016-05-05 08:00:14 +03: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-07 03:45:34 +03:00
|
|
|
WinCompositorWidget::WinCompositorWidget(
|
|
|
|
const WinCompositorWidgetInitData& aInitData,
|
2017-01-13 01:29:42 +03:00
|
|
|
const layers::CompositorOptions& aOptions)
|
|
|
|
: CompositorWidget(aOptions),
|
2019-11-01 14:01:34 +03:00
|
|
|
mSetParentCompleted(false),
|
2017-01-13 01:29:42 +03:00
|
|
|
mWidgetKey(aInitData.widgetKey()),
|
2016-07-01 11:15:16 +03:00
|
|
|
mWnd(reinterpret_cast<HWND>(aInitData.hWnd())),
|
2020-01-08 21:35:22 +03:00
|
|
|
mCompositorWnds(nullptr, nullptr) {
|
2016-05-05 08:00:13 +03:00
|
|
|
MOZ_ASSERT(mWnd && ::IsWindow(mWnd));
|
2016-05-05 08:00:13 +03:00
|
|
|
}
|
|
|
|
|
2018-03-29 05:21:47 +03:00
|
|
|
WinCompositorWidget::~WinCompositorWidget() { DestroyCompositorWindow(); }
|
|
|
|
|
2016-07-01 11:15:16 +03:00
|
|
|
uintptr_t WinCompositorWidget::GetWidgetKey() { return mWidgetKey; }
|
2016-05-05 08:00:14 +03:00
|
|
|
|
2018-03-29 05:21:47 +03:00
|
|
|
void WinCompositorWidget::EnsureCompositorWindow() {
|
2019-02-07 10:01:41 +03:00
|
|
|
if (mCompositorWnds.mCompositorWnd || mCompositorWnds.mInitialParentWnd) {
|
2018-03-29 05:21:47 +03:00
|
|
|
return;
|
|
|
|
}
|
2019-02-07 10:01:41 +03:00
|
|
|
|
|
|
|
mCompositorWnds = WinCompositorWindowThread::CreateCompositorWindow();
|
|
|
|
UpdateCompositorWnd(mCompositorWnds.mCompositorWnd, mWnd);
|
|
|
|
|
|
|
|
MOZ_ASSERT(mCompositorWnds.mCompositorWnd);
|
|
|
|
MOZ_ASSERT(mCompositorWnds.mInitialParentWnd);
|
2018-03-29 05:21:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void WinCompositorWidget::DestroyCompositorWindow() {
|
2019-02-07 10:01:41 +03:00
|
|
|
if (!mCompositorWnds.mCompositorWnd && !mCompositorWnds.mInitialParentWnd) {
|
2018-03-29 05:21:47 +03:00
|
|
|
return;
|
|
|
|
}
|
2019-02-07 10:01:41 +03:00
|
|
|
WinCompositorWindowThread::DestroyCompositorWindow(mCompositorWnds);
|
|
|
|
mCompositorWnds = WinCompositorWnds(nullptr, nullptr);
|
2018-03-29 05:21:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void WinCompositorWidget::UpdateCompositorWndSizeIfNecessary() {
|
2019-02-07 10:01:41 +03:00
|
|
|
if (!mCompositorWnds.mCompositorWnd) {
|
2018-03-29 05:21:47 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
LayoutDeviceIntSize size = GetClientSize();
|
|
|
|
if (mLastCompositorWndSize == size) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-11-01 14:01:34 +03:00
|
|
|
// This code is racing with the compositor, which needs to reparent
|
|
|
|
// the compositor surface to the actual window (mWnd). To avoid racing
|
|
|
|
// mutations, we refuse to proceed until ::SetParent() is called in parent
|
|
|
|
// process. After the ::SetParent() call, composition is scheduled in
|
|
|
|
// CompositorWidgetParent::UpdateCompositorWnd().
|
|
|
|
if (!mSetParentCompleted) {
|
|
|
|
// ::SetParent() is not completed yet.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
MOZ_ASSERT(mWnd == ::GetParent(mCompositorWnds.mCompositorWnd));
|
|
|
|
|
2018-03-29 05:21:47 +03:00
|
|
|
// Force a resize and redraw (but not a move, activate, etc.).
|
2019-11-01 14:01:34 +03:00
|
|
|
if (!::SetWindowPos(
|
|
|
|
mCompositorWnds.mCompositorWnd, nullptr, 0, 0, size.width,
|
|
|
|
size.height,
|
|
|
|
SWP_NOACTIVATE | SWP_NOCOPYBITS | SWP_NOOWNERZORDER | SWP_NOZORDER)) {
|
2018-03-29 05:21:47 +03:00
|
|
|
return;
|
|
|
|
}
|
2019-11-01 14:01:34 +03:00
|
|
|
|
2018-03-29 05:21:47 +03:00
|
|
|
mLastCompositorWndSize = size;
|
|
|
|
}
|
|
|
|
|
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 15:50:44 +03:00
|
|
|
// Creates a new instance of FxROutputHandler so that this compositor widget
|
|
|
|
// can send its output to Firefox Reality for Desktop.
|
2019-09-04 22:58:51 +03:00
|
|
|
void WinCompositorWidget::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 15:50:44 +03:00
|
|
|
MOZ_ASSERT(mFxrHandler == nullptr);
|
2019-09-04 22:58:51 +03:00
|
|
|
|
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 15:50:44 +03:00
|
|
|
mFxrHandler.reset(new FxROutputHandler());
|
2019-09-04 22:58:51 +03:00
|
|
|
}
|
|
|
|
|
2016-05-05 08:00:13 +03:00
|
|
|
} // namespace widget
|
|
|
|
} // namespace mozilla
|