| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This lets the compositor avoid needing to clear and blend the
pixels behind the background surface made by swaybg.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that the background is always opaque.
This is a significant change; before, if no background color was
specified, images were drawn onto an initially transparent buffer,
leaving some of the content behind swaybg visible if the image was
alpha transparent or if the 'fit' or 'center' scaling modes were used
and the image aspect ratio did not match, or the image was not large
enough. As the purpose of a wallpaper/background program is to draw
the pixels behind all other interface items, this transparency is
neither a required nor a very useful behavior.
Sway version >= 1.9 by default clears frames with black, so this
change should have no visible impact. Users of other compositors
may need to adjust their images or specify the --color flag.
|
|
|
|
|
|
| |
Calling get_buffer_size on a newly created swaybg_output, before a
config is assigned to a swaybg_output, is unnecessary and yields a
null pointer dereference.
|
|
|
|
|
|
|
|
|
|
|
| |
The fractional scale protocol does not guarantee that a preferred
fractional scale value is provided before the surface is mapped.
Therefore, use the (integral) output scale value until a fractional
scale is available.
Also: wl_output.scale is not guaranteed to be sent if the initial
output scale is 1 (although Sway always sends it). Set the default
output scale value.
|
|
|
|
|
| |
And if available, use wp-viewporter to submit buffers whose size
exactly matches the "physical" pixel dimensions of the output.
|
|
|
|
|
|
|
|
| |
This commit introduces a new `draw_buffer` function which handles both
the creation of single-pixel and wl_shm buffers, and a `get_buffer_size`
to give the required buffer size in both cases. This reorganization
will it easier in the future to support shm buffers in conjunction
with wp_viewport, for use with wp_fractional_scale_v1.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before this change, parse_color() and is_valid_color() behaved slightly
differently: parse_color() accepted both colors with and without alpha,
with optional leading #, while is_valid_color() forbade alpha and required
a leading # character. This commit merges the two functions into one
simpler function that forbids alpha and allows an optional leading #.
(Alpha values are forbidden because backgrounds should be opaque; a
leading # is optional to make shell scripts easier to write.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`gcc-14` added a new `-Walloc-size` warning that makes sure that size of
an individual element matches size of a pointed type:
https://gcc.gnu.org/PR71219
`swaybg` triggers it on `calloc()` calls where member size is used as
`1` (instead of member count):
../main.c:492:32: error: allocation of insufficient size '1' for type 'struct swaybg_output_config' with size '48' [-Werror=alloc-size]
492 | config = calloc(sizeof(struct swaybg_output_config), 1);
| ^
|
|
|
|
| |
References: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/104
|
| |
|
|
|
|
| |
References: https://github.com/swaywm/swaybg/issues/35
|
|
|
|
|
|
|
|
|
|
|
| |
The contents of the buffer associated to an output depend only
on the output config (which does not change at runtime), and the
buffer dimensions.
When the compositor changes the output scale, it often sends a
configure event which exactly compensates for the scale change,
so that the size of the buffer needed for the surface remains
the same. Thus no new frame needs to be rendered.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change keeps the full-size cairo_surface_t objects unloaded
until they are needed to produce buffers for the outputs' surfaces.
This can slow down background rendering when output scales or sizes
change, or when a new output is created; in exchange, it significantly
reduces the amount of memory that swaybg must retain while it is
not rendering something.
To reduce peak memory usage, dirty outputs are redrawn drawn in batches
grouped by which image they use. This ensures at most one image is
loaded at a time.
|
|
|
|
|
|
|
|
|
| |
Caching these actually increased memory usage after startup;
compositors like Sway tend to release the buffer on receipt (since
they have already copied the shm buffer to an OpenGL equivalent)
so the shm buffer is no longer needed after being used. Outputs
(when not in nested mode) are generally only configured/drawn once,
so there is no point in caching data for the future.
|
|
|
|
|
| |
This reduces memory usage and startup time when different configs
load the same image.
|
|
|
|
|
|
|
| |
When outputs are dynamically resized, as can happen when sway
is run nested with its wayland or x11 backend, layer shell programs
receive a stream of configure events. In such cases, only rendering
a frame for the last configure event avoids wasted computation.
|
|
|
|
| |
Same as https://github.com/swaywm/sway/pull/6262
|
|
|
|
|
|
|
| |
Before, `--output "*"` had to be specified on the cli before
any appearance options if trying to configure all outputs.
However, the manpage states that all outputs would be used by
default if none were specified.
|
| |
|
|
|
|
|
|
|
|
|
| |
This makes it so there will only be one swaybg instance running
instead of one per output. swaybg's cli has been changed to a xrandr
like interface, where you select an output and then change properties
for that output and then select another output and repeat. This also
makes it so swaybg is only killed and respawned when a background
changes or when reloading.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit mostly duplicates the wlr_log functions, although
with a sway_* prefix. (This is very similar to PR #2009.)
However, the logging function no longer needs to be replaceable,
so sway_log_init's second argument is used to set the exit
callback for sway_abort.
wlr_log_init is still invoked in sway/main.c
This commit makes it easier to remove the wlroots dependency for
the helper programs swaymsg, swaybg, swaybar, and swaynag.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
render_background_image alters the scale that cairo uses. Depending on
the image mode, resolution, and image size, this may cause the surface
to be rendered increasingly smaller. By calling cairo_save and
cairo_restore, any changes to the cairo settings by the function are
not kept as a side effect.
The surface that swaybg uses is also now cleared before rendering a frame.
This is needed to avoid artifacts on resolution or scale changes with
certain combinations of image modes, resolutions, and image sizes. This
was also part of the increasingly smaller background visual since it
made it so it was not obvious the region being rendered to was smaller
and caused an increasing number of smaller images to be appear for each
hotplug.
|
|
|
|
|
|
| |
This allows for a color to be set when the wallpaper does not fill the
entire output. If specified, the fallback color is also used when the
image path is inaccessible.
|
|
|
|
|
| |
When turning off displays via DPMS, swaybar and swaybg still tried to
render, but did not get a valid buffer, causing them to crash.
|
| |
|
| |
|
| |
|
|
|
|
| |
swaylock will use it too
|
|\
| |
| | |
swaybg: set an empty input region
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
| |
Since it now includes SOLID_COLOR this is a more appropriate name.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This adds HiDPI support to swaybar, swaybg, and swaylock.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 99bda4afe27d9e5723ab6b0ebe5eabb0caaa8eeb.
It turned out that code to handle swaybg as shell surface was broken so we don't
want to make swaybg a shell surface until this has been fixed.
|