`LOG` is defined by `nsWindow.h` for a shortcut of `MOZ_LOG` for generic use
under `widget/gtk`. However, some cpp files do `#undef LOG` and redefine it.
This causes the CPP file order important in unified cpp files since a CPP
file's `LOG` may be redefined unexpectedly with changing the unified order
and/or group. Therefore, each cpp file should define its own macro name
instead of redefining `LOG`.
Differential Revision: https://phabricator.services.mozilla.com/D115978
In preperation to reuse it for a second `WindowSurface` backend as well
as `NativeLayerWayland`.
There should be no fundamental changes, just some restructuring:
- Make `WaylandShmBuffer` as generic as possible so it can be easily
reused
- Remove resizing of buffers and create new ones instead. This is in
order to reduce complexety at a likely low cost.
- Make more use of refcounting, in order to make it easier to ensure
things don't vanish beneath our feet.
- Make some parts of the code more Mozillian/C++y, as opposed to
Gnome-/C-ish, in order to make it easier to read for other FF-devs.
- Fix some complains of static analysis
Differential Revision: https://phabricator.services.mozilla.com/D115083
Fractional scaling currently comes at a high performance cost as we
only support integer scaling for rendering. The overdraw ratio is
something like (ceil(scale) / scale)^2, which for 125% scaling means
we're drawing 2.56 times as much as we should.
In theory we already support everything needed to have proper fractional
scaling: Webrender support appears to be in great shape and on the Wayland
side we can use the wp_viewporter protocol to have arbitrary
buffer size <-> surface size relationships. The main blocker remains the
lack of proper negotiation between client and compositor about the
optimal buffer size.
In order to speed up the upstream discussion, lets implement it via a
fixed value that can be set in `about:config` for testing purposes
(`widget.wayland.fractional_buffer_scale`).
It will, of course, require wp_viewporter support from the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D113321
- When there's cached drawing from previous rendering and widget size changes, we can't paint the cached drawings.
Instead create a new wl_buffer with size of MozContainer and clear the cache.
Depends on D104710
Differential Revision: https://phabricator.services.mozilla.com/D104711
- Recently we use size allocation event to create wl_subsurface of MozContainer. Unfortunately size allocation event
is not called when a window is opened second time, as its size is already set. Use map_event to create
wl_subsurface in this case.
Differential Revision: https://phabricator.services.mozilla.com/D104551
- Try to set subsurface offset even if we mozcontainer size allocation is not finished. Use window decoration size for it.
- Add more logging to mozcontainer code.
Depends on D104549
Differential Revision: https://phabricator.services.mozilla.com/D104550
Rework wl_subsurface creation in these steps:
1) moz_container_wayland_size_allocate() handler is called when
mContainer size/position is known.
It calls moz_container_wayland_surface_create_locked(), registers
a frame callback handler
(moz_container_wayland_frame_callback_handler()).
2) moz_container_wayland_frame_callback_handler() is called
when wl_surface owned by mozContainer is ready.
We call initial_draw_cbs() handler and we can create our wl_subsurface
on top of wl_surface owned by mozContainer.
Also size wl_buffer at WindowSurfaceWayland according to mozcontainer size,
don't use nsWindow bounds for it.
Differential Revision: https://phabricator.services.mozilla.com/D104549
- Try to set subsurface offset even if we mozcontainer size allocation is not finished. Use window decoration size for it.
- Add more logging to mozcontainer code.
Depends on D104549
Differential Revision: https://phabricator.services.mozilla.com/D104550
Rework wl_subsurface creation in these steps:
1) moz_container_wayland_size_allocate() handler is called when
mContainer size/position is known.
It calls moz_container_wayland_surface_create_locked(), registers
a frame callback handler
(moz_container_wayland_frame_callback_handler()).
2) moz_container_wayland_frame_callback_handler() is called
when wl_surface owned by mozContainer is ready.
We call initial_draw_cbs() handler and we can create our wl_subsurface
on top of wl_surface owned by mozContainer.
Also size wl_buffer at WindowSurfaceWayland according to mozcontainer size,
don't use nsWindow bounds for it.
Differential Revision: https://phabricator.services.mozilla.com/D104549
Use gfx::DataSourceSurface instead of gfxImageSurface to cache drawing and don't use blending
when we paint cached images to Wayland buffer.
Differential Revision: https://phabricator.services.mozilla.com/D102238
Dump wayland buffers as png images when MOZ_WAYLAND_DUMP_WL_BUFFERS env variable is set and also log that.
The images are stored in recent working directory unless MOZ_WAYLAND_DUMP_DIR is set.
Differential Revision: https://phabricator.services.mozilla.com/D101581
- Move nsWaylandDisplay::SyncBegin() out of FlushPendingCommitsLocked() call to avoid a deadlock there
- Rename FlushPendingCommitsInternal() to FlushPendingCommitsLocked() to clearly state it operates on locked surface only.
- Implement nsWaylandDisplay::QueueSyncBegin() which delays SyncBegin() execution untill recent event batch is finished
and use it instead of SyncBegin().
Differential Revision: https://phabricator.services.mozilla.com/D100384
As WindowSurfaceWayland can be acessed from various threads we need to guard public interface by mutex to avoid
threading issues. We also can't delete WindowSurfaceWayland internals untill it's used.
Depends on D100313
Differential Revision: https://phabricator.services.mozilla.com/D100314
Use g_timeout for delayed/pending commits instead of PostDelayedTask()/NewRunnableFunction()
and remove an active timeout when WindowSurfaceWayland is deleted.
Differential Revision: https://phabricator.services.mozilla.com/D100313
Wayland protocol does not include a mechanism how to inform compositor about deleted frame callbacks.
We delete a callback only locally on client side and it remains active at server (compositor) side.
When large amount of callbacks is accumulated at server Firefox is closed due to OOM
so we need to keep frame callback on local side untill is fired and don't create a new one.
Differential Revision: https://phabricator.services.mozilla.com/D95678
- Make WaylandAllocateShmMemory() fallible.
- Implement WaylandReAllocateShmMemory() to re-allocate Shm pool.
- Remove WaylandShmPool::Resize() and use WaylandShmPool::Create() only.
- Implement and use WaylandShmPool::Release().
- Make WindowSurfaceWayland::CreateWaylandBuffer() as fallible.
Differential Revision: https://phabricator.services.mozilla.com/D94735
- Make WaylandAllocateShmMemory() fallible.
- Implement WaylandReAllocateShmMemory() to re-allocate Shm pool.
- Remove WaylandShmPool::Resize() and use WaylandShmPool::Create() only.
- Implement and use WaylandShmPool::Release().
- Make WindowSurfaceWayland::CreateWaylandBuffer() as fallible.
Differential Revision: https://phabricator.services.mozilla.com/D94735
Track delayed commits in a global list and don't store them in actual wayland surfaces.
When a delayed commit is called, check that the associated wayland surface is still valid.
Differential Revision: https://phabricator.services.mozilla.com/D92432
The only thing in nsIFrame.h that was using it was the implementation
of a templated method, which could be moved to nsIFrameInlines.h.
Depends on D91504
Differential Revision: https://phabricator.services.mozilla.com/D91505
