Wayland support?
Riteo opened this issue · comments
Hi! This looks like a really nice project! I wonder if it would make sense to support Wayland here. I could give a hand if you're interested.
Given Fenster's API, it'll be quite tough to have HiDPI support for Wayland. The main issue is that the client expects a fixed viewport with an image buffer of the same size, so we can't let the user have a larger image buffer for scaling. If we add a new API, the user will have to worry a lot more when blitting images onto Fenster.
I think Wayland support can still be done with something like shared buffers though. It'll just be a lot more code, since Wayland's client API is a lot more code than X's higher-level libraries. We'll also need something like libdecoration added on top, probably.
Given Fenster's API, it'll be quite tough to have HiDPI support for Wayland. The main issue is that the client expects a fixed viewport with an image buffer of the same size, so we can't let the user have a larger image buffer for scaling. If we add a new API, the user will have to worry a lot more when blitting images onto Fenster.
AFAICT there's no X11/Windows/MacOS HiDPI support either, so I think that there should be no problem.
I think Wayland support can still be done with something like shared buffers though.
Yup, they would work fine in this application.
It'll just be a lot more code, since Wayland's client API is a lot more code than X's higher-level libraries.
That's my biggest concern too, there are few shortcuts I can think of.
We'll also need something like libdecoration added on top, probably.
I'm not really fond of libdecoration and I'd really like to avoid such an extra dependency if possible. Perhaps we could make some "inline" decoration drawing routine? I know that it would make the header potentially bigger, but that would be better than a whole (extra) dynamically linked library IMO.
AFAICT there's no X11/Windows/MacOS HiDPI support either, so I think that there should be no problem.
That's true, however being a Wayland app, I think it should at least have some ability to render without being blurry on modern computers.
Perhaps just using nearest-neighbor integer scaling would still yield better results than letting the compositor scale up.
I'm not really fond of libdecoration and I'd really like to avoid such an extra dependency if possible. Perhaps we could make some "inline" decoration drawing routine?
That's fair. Given the simplicity of this library, I think we can get away with rendering a blank deco only once with basic buttons.
Perhaps just using nearest-neighbor integer scaling would still yield better results than letting the compositor scale up.
Considering that this library implies being akin to old school stuff ("Borland BGI or drawing things in QBASIC or INT 10h") I agree that it would probably be the best option. IIRC HiDPI buffers are already scaled with integer scaling, at least on sway. Is the filter used for HiDPI buffers defined somewhere in the spec?
That's fair. Given the simplicity of this library, I think we can get away with rendering a blank deco only once with basic buttons.
Great. Although, damn, just remembered that we should also handle mouse window dragging/resizing. It shouldn't be hard at all thanks to stuff like xdg_toplevel::resize, just wanted to point that out.
Is the filter used for HiDPI buffers defined somewhere in the spec?
I don't think so, but afaik, most compositors use whatever OGL has built-in, which is bilinear filtering.
@diamondburned I can think of a few ways of fixing it in one way or another, but this is IMO secondary stuff (despite being certainly unpleasant). We could see it later if this feature is wanted and once it's started (it'll take some time from my part as I'm currently very busy due to end-of-term school stuff).