SDL2 video ideas, revisited

[Mega-JC]

This GH issue aims to both port and superseed https://github.com/pygame/pygame/issues/2691 , to help bring the _sdl2.video API to a stage that allows for straightforward porting to C, as proposed in #1929 , and a proper adoption in pygame.

The idea here is to have a list of actionable ideas in a checklist, which can either be branched out into separate issues or can be linked to a PR. The list can also be expanded by repository admins if necessary.

None of these ideas are final, and discussion around them is encouraged.

• [ ] Give Texture and Image get_width(), get_height(), and get_size() methods like surfaces
  • Reasoning: Hard to document, potentially confusing
• [ ] Remove readonly attributes from Window, Texture and Renderer
• [ ] Rename Renderer.present() to .flip() / .update()
• [ ] Create API for supporting multiple windows in pygame.display
• [ ] Change Renderer.fill_rect() to impersonate Surface.fill()
• [ ] *Change `Renderer.draw_` methods to take in a color directly**
  • Reasoning: The current “C like” set color flag then draw system is uncommon in pygame.
• [ ] pygame.draw compatibility for Texture objects
  • Reasoning: A unified system for drawing that works for both Surface and Texture. SDL_RenderGeometry() (SDL 2.0.18) might come in handy.
  • Other ideas:
    • A dedicated drawing module for Textures, using either SDL_RenderGeometry() or SDL2_gfx, called e.g. gpudraw , given the complexity of pygame.draw and plans for merging gfxdraw into it
• [ ] Eliminate Image objects, add Texture.subtexture
• [ ] Add compatibility for drawing Surface unto Renderer
  • Reasoning: By e.g. making a streaming Texture the size of the Renderer, and putting surface data into there before drawing it onto the Renderer, we could save people the trouble of adding a conversion step for dynamic surfaces like Text rendered every frame, as some things are always going to be Surfaces.
• [ ] pygame.transform compatibility for Texture objects

[robertpfeiffer]

We might be able to lock and memory-map a texture to a write-only PyGame Surface: https://wiki.libsdl.org/SDL2/SDL_LockTexture, but please understand the performance implications

[yunline]

• Remove readonly attributes from Window, Texture and Renderer

There are currently 2 readonly attributes in Window. One is display_index (which i think is useful and doesn't need to be removed).

Another one is id. We don't need to get the SDL window id. We've already had an 'id()' function in python. A SDL window should be represented by only one pygame Window object, so that we can use id(window) instead of window.id. However, currently, one SDL window can be represented by multiple pygame Window objects:

import pygame
from pygame._sdl2 import video

pygame.display.set_mode((64,64))

w2=video.Window.from_display_module()
w1=video.Window.from_display_module()

print(id(w1))
print(id(w2))

print(w1.id)
print(w2.id)

# pygame-ce 2.1.4.dev1 (SDL 2.0.22, Python 3.10.6)
# 2765039017232
# 2765576044496
# 1
# 1

[Starbuck5]

@yunline The functionality doesn't need to be removed, I was just thinking of removing the attributes and turning them into explicit getters instead.

[yunline]

The functionality doesn't need to be removed, I was just thinking of removing the attributes and turning them into explicit getters instead.

@Starbuck5 Shall other attributes turned into getters and setters? Like:

[robertpfeiffer]

Another one is id. We don't need to get the SDL window id. We've already had an 'id()' function in python. A SDL window should be represented by only one pygame Window object, so that we can use id(window) instead of window.id. However, currently, one SDL window can be represented by multiple pygame Window objects.

Python object ID is different from window ID, and yes, getting a window from the display module is not idempotent for dumb implementation and memory management reasons, but those are different types of ID to begin with! I don't see a way to solve the memory management problems completely unless we replace display.c with Cython or similar in the long term.