buffer width and height are only u16

[LoganDark]

This limits the window to 65,536 * 65,536. :/

Is there any reason for this limitation, does a backend mandate it or something?

[i509VCB]

I know X11 limits window dimensions to a u16. Wayland is everything greater than zero within an i32 (so effectively a u31).

[LoganDark]

I know X11 limits window dimensions to a u16.

This is a platform-specific-panic sort of situation - if you ever do encounter a window bigger than that, anyway.

[kchibisov]

In what setup would you need to create a buffer that large? I'm not even sure you can achieve a resolution like that, and both windows and X11 limit to u16?

65536 * 65536 window will consume 128 GB of memory, sure, you'll have a window that large.

Not even speaking about bandwidth you'd need for it.

[LoganDark]

In what setup would you need to create a buffer that large? I'm not even sure you can achieve a resolution like that, and both windows and X11 limit to u16?

65536 * 65536 window will consume 128 GB of memory, sure, you'll have a window that large.

Not even speaking about bandwidth you'd need for it.

You only have to exceed it in 1 dimension for there to be an issue, and 8K monitors famously have like 7680 pixels across, it's feasible to exceed 65536 today with like 8–9 of these monitors in a row.

This is somewhat of a contrived scenario but 65536 is only like 1 or 2 orders of magnitude off from a normal desktop setup which makes me uncomfortable. I would much rather softbuffer use u32 internally even if 80% of its backends will panic. Because then maybe those backends can be updated without breaking changes if the API is future-proof.

[john01dav]

I agree that we should fix this. It was an error that I made to make it u16 in the first place. Even if some backends can't handle it there's no reason that the API needs to express this particular limitation. We could have some function to check the maximum size I guess, that returns a different number depending on the backend.

[kchibisov]

8–9 of these monitors in a row.

128GB of memory for a single frame, sure you have that many video memory for a single window on a GPU. maybe in 50 years. Like what you describe isn't possible and no system will ever handle that in 2 decades or unless we have RAM in TB instead of GB. So with 32TB of ram I'll be comfortable using such thing.

Because then maybe those backends can be updated without breaking changes if the API is future-proof.

Breaking change to WinAPI/X11 protocol btw.

[john01dav]

8–9 of these monitors in a row.

128GB of memory for a single frame, sure you have that many video memory for a single window on a GPU. maybe in 50 years. Like what you describe isn't possible and no system will ever handle that in 2 decades or unless we have RAM in TB instead of GB. So with 32TB of ram I'll be comfortable using such thing.

Because then maybe those backends can be updated without breaking changes if the API is future-proof.

Breaking change to WinAPI/X11 protocol btw.

You've given reasons that we could probably get away with not doing it for now, but it's always better to make breaking API changes earlier in a project rather than later. Is there some downside to getting ahead of this possible issue that we're missing? It's not like it's increased complexity or anything like that.

[LoganDark]

128GB of memory for a single frame

idk my calculations say nine 8K monitors would be 298,598,400 pixels, or in other words 900MB for 24 bpp, because I am not taking about 64k x 64k I'm talking about 64k x anything

Breaking change to WinAPI/X11 protocol btw.

softbuffer can change its backend internals without changing the public API surface of softbuffer itself

[ids1024]

it's feasible to exceed 65536 today with like 8–9 of these monitors in a row

"Feasible" may be an exaggeration. I don't think you'll find any GPU that can drive 9 8k displays. Can they even handle 2? If so that would require displays connected to 5 different graphics cards. At best "technically possible" rather than "feasible".

I don't really expect this to be an issue in the foreseeable future. But I think it makes sense to use 32-bit values when that's what winit uses (as well as glutin), and is technically supported on some backends.

[i509VCB]

Maybe the compromise to take here would be to introduce a sort of Limits type you can query from a Context that way backends which support higher horizontal resolutions can advertise that.

[LoganDark]

"Feasible" may be an exaggeration. I don't think you'll find any GPU that can drive 9 8k displays.

you're right

I don't really expect this to be an issue in the foreseeable future. But I think it makes sense to use 32-bit values when that's what winit uses (as well as glutin), and is technically supported on some backends.

Yeah, like I said up above:

This is somewhat of a contrived scenario but 65536 is only like 1 or 2 orders of magnitude off from a normal desktop setup which makes me uncomfortable. I would much rather softbuffer use u32 internally even if 80% of its backends will panic.

---

Maybe the compromise to take here would be to introduce a sort of Limits type you can query from a Context that way backends which support higher horizontal resolutions can advertise that.

Not... really? You'd have to allow for u32 values if you want to permit backends that support that range