Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MemoryRenderBuffer rounds size to scale #1292

Open
YaLTeR opened this issue Jan 18, 2024 · 1 comment
Open

MemoryRenderBuffer rounds size to scale #1292

YaLTeR opened this issue Jan 18, 2024 · 1 comment

Comments

@YaLTeR
Copy link
Contributor

YaLTeR commented Jan 18, 2024

let scale = 2;

let (width, height) = (99, 99);
let mut data = vec![];
let mut a = false;
for _ in 0..width * height {
    if a {
        data.extend([255, 255, 255, 255]);
    } else {
        data.extend([0, 0, 0, 0]);
    }
    a = !a;
}

let buffer = MemoryRenderBuffer::from_memory(
    &data,
    Fourcc::Argb8888,
    (width, height),
    scale,
    Transform::Normal,
    None,
);

This will draw the buffer at 98x98 instead of 99x99, resulting in this:

image

@cmeissl
Copy link
Collaborator

cmeissl commented Jan 19, 2024

The MemoryRenderBuffer was designed to work like the wayland surface element.

The size of the MemoryRenderBuffer is not in physical space, it uses buffer space. The scale you provide defines
the buffer scale. So to get the logical size of the element you would divide the buffer size by the buffer scale.
For the transform from logical space to physical space during rendering the output scale is used.

A wayland surface with buffer and scale would result in a protocol error as the size is not a multiple of the scale.
That is also one of the reason why the relatively new fractional scale protocol is doing things a bit differently.
It will always provide a buffer scale of 1 and use viewporter to set a specific logical size of the surface. But note
that this will still result in some rounding and some size are just not possible to represent correctly.

We can definitely improve the docs on the element to clarify how the scale correlates to the size.
But imo it's not a bug, more a shortcoming of the element which we should address.

While a wayland surface has this limitation because of the protocol spec, there is no requirement to have the same
limitations for the other render elements. We just have to be careful when lifting this limitation to not cause alignment
issues (e.g. gaps or overlaps) between the elements because of the necessary rounding in the wayland surface element.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants