We would pass `physical_size_to_slint(&self.winit_window().inner_size())`, which is
identical to `slint::Window::size()`, which
calls `size()` on the WindowAdapter, which
returns the above.
show() used to create the window, which required access to the event
loop (target), which in turn required workarounds like in #1603. Since
the winit window exists now in show(), we don't need this workaround
anymore.
The same applies to hide(), we don't need an event loop target, all we
need is the event loop proxy to dispatch a WindowHidden event.
Now that we always create a window, we end up also creating an event
loop, and that's inherently incompatible with the rust test harness that
creates threads.
We can try to re-enable this later on platforms where we can run an
event loop in a thread. I have a local WIP patch for that.
This simplifies the logic for how to apply window related requests as
they can be applied to the winit window immediately.
It also simplifies the state handling in the WinitWindowAdapter, as
there's no more distinction between mapped and unmapped. We always map
now (winit does).
One related change in core is that the window properties are now sent to
the backend before calling show(), instead of after.
The creation of the renderer might fail, for example if we tried to
create an OpenGL renderer on a display that doesn't support OpenGL. We
should catch that in the future and fall back to the software renderer.
In order for GLX support to work, we need to create the X11 window with
the same visual as in the GLX configuration. That requires delaying
the creation of the window.
This is done in four parts:
- The window builder is re-introduced in the winit backend create
internal renderer interface.
- The glcontext helper code for wasm was moved into a separate function
(less indentation).
- The loop over different display preferences was replaced with a
preference to the "window system native GL interface" over EGL,
which should achieve the same as the fix for #2162. Upstream glutin
defaults to this and so do various downstream projects.
- Use glutin-winit for the actual display selection.
This covers the FemtoVG bits of #2269
This will be needed for a future experiment. Unlike the Skia renderer,
which operates on raw window handles, the FemtoVG renderer exposes a
different interface where it assumes that the caller takes care of the
OpenGL context state. This means more boilerplate remains in the winit
backend, including the glutin dependency. The upside is that it will
allow using the FemtoVG renderer in environments without glutin.
In order to work in an environment without fontconfig or memmap, the
crate has two features:
- fontconfig (set when we anticipate fontconfig to be available at
run-time and libloading being available at compile time).
- diskfonts (set when we want to be able to load fonts from disk)
The winit crate enables fontconfig on "Linux" and diskfonts on !wasm.
Having a const generic for that didn't turn to be a good API.
Also made the C++ side more difficult
(Also renamed buffer_stride to pixel_stride)
Closes#2135
The crate is an internal crate until the API has been polished and
documented, after which we can call slint-renderer-skia for example.
This also duplicates a little bit of the glutin setup code, because
that would otherwise have to go into another shared crate.
The default impl of unregister_component in WindowAdapterSealed would call free_graphics_resources
on the rendere. Any re-implementation would have to do the same,
which the winit backend forwarded through
the winit backend specific internal renderer interface.
Instead, the original call site for unregister_component now calls
free_graphics_resources and unregister_component (for accessibility tree dirty notification).
Replace register_root_component in the WindowAdapterSealed altogether with
a default font size getter on the renderer.
This is overall simpler and allows removing the doc-hidden getter in the software renderer.
Permit the style metrics to provide a `default-font-size` and bind that
to the `Window` if set. If not provided, then the backend can set a
`default-font-size`. By ensuring that the value is non-zero at run-time,
we can later introduce a rem unit that can act as factor relative to
this non-zero font size.
When opting into the Skia renderer, we default to metal on macOS and D3D on Windows.
However if you want to develop a cross-platform application with Skia and
for example rely on OpenGL to be able to implement an OpenGL underlay or overlay,
then we need the ability to explicitly opt into skia's GL renderer.
cc #1445
