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

pygame.image.load #3273

Closed
mentat51 opened this issue Dec 19, 2024 · 5 comments
Closed

pygame.image.load #3273

mentat51 opened this issue Dec 19, 2024 · 5 comments

Comments

@mentat51
Copy link

The doc of pygame.image.load says :
You will often want to call pygame.Surface.convert() with no arguments, to create a copy that will draw more quickly on the screen.

Is it often or always ?

If it's often, in which case ?

if it's always, the image.load function can make this task directly (convert or convert_alpha depending of the image), no ?

I've seen a lot of pygame's example where the images are loaded but not converted. This can slowdown the blits.

@damusss
Copy link
Member

damusss commented Dec 19, 2024

Hi :)
It's not always, because pygame isn't an engine so it gives you freedom. when the image is loaded it keeps whatever pixel format was inside the file, and depending on your project you might want that since pygame isn't just about games. It's often because you often load images to eventually blit them, and that would become faster if you convert the image to the pixel format of the screen. The function could never make this automatic, because to convert with no arguments you actively need an open display, but you can load images and manipulate surfaces without ever creating a window. The documentation isn't too unclear about this, it's saying that if you want it to draw faster (which is often the case), the you probably want to convert it. We also can't ignore that convert_alpha exists aswell, and the function cannot choose arbitrarly between the two.
That's what I think at least.
I'm not aware of official pygame-ce examples not converting before blitting. If that's the case, I agree that it would be better to modify them.

@mentat51
Copy link
Author

Thanks for your fast answer !
I understand your arguments.
I'm not talking about OFFICIAL pygame-ce examples, don't worry.

Maybe a warning if we try to blit a not converted surface may be useful to tell us we don't use pygame-ce correctly ?

@damusss
Copy link
Member

damusss commented Dec 19, 2024

No worries :) I still think your concearn was valid. Non official examples always don't use the best available, some official examples don't follow all conventions either but with time they will get better.
Your intent with the warning is genuine, but I'm afraid such a big behavioural change isn't possible given how much general and used blitting is. But, when SDL3 will be out, some refactoring will be made and we will try to release extensive functionality to view a surface pixel format, just like you could in C. in the future you could pass blits to a validator function that compares the pixel formats, and reminds you to convert them (manual, but easy). Don't take this as an official feature announcement, I've tried to add pixel format information to pygame-ce 2 but it was delayed to worry about it for sdl3, so yeah.

Almost forgot, if the idea of adding a debug mode of pygame goes through, your warning could actually be a good idea, just saying.

@Starbuck5
Copy link
Member

This is a great idea, but damus is right about it being infeasible to implement given the fact that images can be loaded before the display is set up, and convert() doesn't know what to do before the display is set up.

There are valid use cases where someone would blit surfaces that aren't converted. Like if someone was using pygame.camera support for webcams and getting raw frames out, it's not worth converting() and then blitting if the webcam frame is only going to be around for a frame or two. Same with other streaming applications. I could see it being annoying for experienced users getting warnings about things they know they are doing correctly.

@mentat51
Copy link
Author

Very good argument !
So, I close this.

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

No branches or pull requests

3 participants