Replace get_surface method of Window with surface property

[ankith26]

I know get_surface was added with similarity to pygame.display in mind, but I think having this as a property instead can make things easier and neater for users of this API.

With this, the users would not need to keep track of surface of a window in a separate variable

[MyreMylar]

This makes sense to me. Under the old system there was one display surface to rule them all, but now with multiple windows each special 'flippable' window surface is surely tied to a specific window and becomes invalid if that window is deleted. Making it a property should make this tight relationship between a specific window and a specific flippable surface clearer.

under the old system I used to always get my display surface straight from calling .set_mode() and I imagine many people did and won't particularly miss .get_surface() when switching over.

👍

[Matiiss]

Changes look good, the new API makes sense. Maybe as a property it could be moved above the classmethod in the docs, but that's getting deprecated soon enough so maybe doesn't matter.

[Starbuck5]

I'm skeptical of this, I've been slowly thinking about why off an on for a while.

We need to enforce separation of software rendering and hardware rendering, because if we don't SDL will throw lots of sometimes unclear errors.

With this change people don't have to "opt in" to using a display surface, from their perspective the display surface will always be there. Since it's a property it implies there isn't an action to get it, I feel that properties imply that the attribute is always present.

get_surface also has the advantage of having a very similar semantic to the existing pygame.display.get_surface

[ankith26]

I agree with the current system not enforcing a clear distinction between hardware and software rendering, but IMO get_surface does not help much in this regard either.
The best way to make a clear distinction is to actually make Window a base class (with not much changes to its existing structure), and have two distinct classes, maybe something like SoftwareWindow and HardwareWindow. SoftwareWindow will have things like .flip() and .surface property, whereas HardwareWindow could have things like a .renderer property?

[Starbuck5]

That's an intriguing idea.

I'd suggest SurfaceWindow and RendererWindow as the names. We'd also need OpenGLWindow. (Potentially VulkanWindow and GPUWindow (SDL GPU API coming to SDL3) in the future)