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

hardware scaling #177

Open
jkarneges opened this issue Nov 13, 2023 · 4 comments
Open

hardware scaling #177

jkarneges opened this issue Nov 13, 2023 · 4 comments

Comments

@jkarneges
Copy link

The readme says:

Softbuffer should be used over pixels when its GPU-accelerated post-processing effects are not needed.

When I first read this, it didn't occur to me that "post-processing effects" included scaling. I was thinking it was more about things like CRT simulation. Unfortunately, scaling is often a requirement due to high resolution displays. Anyone doing full frame redraws and desiring good performance (60fps+) will almost certainly need to operate on a smaller buffer that can be scaled up, which pixels can do. I couldn't get acceptable performance with softbuffer and software scaling, although admittedly I didn't try very hard on the scaling algorithm.

I wonder if softbuffer could make an exception and support hardware scaling, if it wouldn't go against the spirit of the project. It feels like an almost table-stakes feature for most real world use.

@kpreid
Copy link
Contributor

kpreid commented Nov 13, 2023

Even without explicitly using GPU APIs, platforms likely have a built-in scaling operation available in their 2D graphics APIs, which could be faster due to knowing platform details, being fused with other necessary copies along the buffer-to-screen path, or actually being GPU-based.

@ids1024
Copy link
Member

ids1024 commented Nov 13, 2023

On Wayland, https://wayland.app/protocols/viewporter can be used to crop and scale a buffer. It doesn't provide a way to control the scaling algorithm, but probably would provide good results if you're careful to use an integer scale factor? If so it could be useful for software-rendered pixel art games.

It's not necessarily supported on all compositors. Though it probably should be. Mir doesn't seem to support it yet, anyway (canonical/mir#2599).

I'm not sure about other platforms.

On most platforms, you shouldn't need this just for handling hiDPI displays, since applications that don't advertise HiDPI support will be scaled automatically. Though the results are ugly with fractional scales. X11 doesn't really seem to have that though, and HiDPI can be a mess there.

@notgull
Copy link
Member

notgull commented Nov 15, 2023

X11 and Windows do not support intrinsic scaling

@ids1024
Copy link
Member

ids1024 commented Nov 15, 2023

On Windows we're currently using BitBlt (comments in SDL said this was the fastest solution when they tried it; but that was a while ago). Looks like https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-stretchblt may work here?

On macOS, would https://developer.apple.com/documentation/quartzcore/calayer/1410746-contentsscale be applicable? I'm not sure.

Anyway, if it works on some platforms, but isn't supported on others, or only sometimes is available, either:

  • The API has to fail when it's not available, and users of softbuffer will need to deal with that
  • softbuffer could have it's own code to scale in software, as a fallback.

For HiDPI uses, some platforms have a specific way to communicate what DPI scale an application should use, and for the application to indicate if it handles the scale itself or needs upscaling (for legacy software, mainly). That doesn't necessarily require handling from Softbuffer, but probably should be discussed in any documentation for this feature.

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

No branches or pull requests

4 participants