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.display.set_mode(vsync=True) prints a warning (2132) #1122

Open
GalacticEmperor1 opened this issue Feb 12, 2023 · 0 comments
Open

pygame.display.set_mode(vsync=True) prints a warning (2132) #1122

GalacticEmperor1 opened this issue Feb 12, 2023 · 0 comments
Labels
display pygame.display Experimental Experimental code

Comments

@GalacticEmperor1
Copy link
Collaborator

Issue №2132 opened by lordmauve at 2020-10-01 10:00:51

When I call pygame.display.set_mode(..., vsync=True), it prints a warning.

Warning: adaptive vsync for OpenGL not available, trying regular

As a user, there's nothing I can do about this. I don't want to be warned.


Comments

# # MyreMylar commented at 2020-10-01 14:24:20

I can see it being useful information when developing and trying to debug a problem related to vsync on a particular system. What is really needed is a -verbose type flag to pygame to produce more warnings and information like this that you don't always want all the time.

Perhaps another environment variable that defaults to off - similar to what we have for the pygame welcome message but in reverse?


# # ghost commented at 2020-10-02 00:38:50

Perhaps another environment variable that defaults to off - similar to what we have for the pygame welcome message but in reverse?

The warnings in display.c are default python warnings that already can be disabled.
So I don't know if a pygame specific variable is really needed... and if it is, it could simply modify the warnings filter.

But I wonder if it should be on or off by default. 🤔 Pygame is, I think, mostly used by people who are learning and hiding warnings by default means that some people would miss them because they don't even know they exist. If they are on by default, they always can be disabled by the programmer for the release version of something.

What is really needed is a -verbose type flag

Multiple warning categories also could be used for this. Only the most important warnings would be displayed by default and the less useful ones (like the one @lordmauve mentioned) would need to be turned on.


# # MyreMylar commented at 2020-10-02 08:26:42

Setting a default warning level and then flipping some above and below that level sounds like a solid plan to me. I think the vsync warning, for example, is likely something that only a relatively advanced user would ever want to know rather than somebody just making their first game.


# # lordmauve commented at 2020-10-02 08:38:05

More important than what developer see is what end users see; I don't want to pass Pygame warnings/announcement to users of my game (or framework).

I try to always [suppress the "hey, you're using Pygame" chatter](https://github.com/lordmauve/wasabi2d/blob/080c5bb041b34405406eace628bde26c67ff30ef/wasabi2d/__init__.py# L6) which in my view is not appropriate (what if every library did that? Would I need to set an environment variable for every dependency?)

Does Pygame need a "release mode" that has a broader effect?

Maybe

pygame.init(quiet=True)

?


# # MyreMylar commented at 2020-10-02 12:37:03

I think its important for us to default to a moderately verbose communication, like the intro prompt with version data, purely because of the userbase of pygame. Most users of pygame aren't using many other libraries they are beginners learning how to code in schools and universities not writing their own modules, and many of them probably don't even know the term dependency. I'd prefer to default to slightly annoying power users rather than making pygame support and development harder for beginners. That is a long running debate though and there are other issues discussing it.

I think handing over control to users as to what kind of warnings and other, non-error output, is produced is the right choice. Maybe three warning levels: 'default', 'verbose', 'quiet'

I will say that for end users of finished pygame apps you should probably just hide the console entirely and not worry about it.


# # ghost commented at 2020-10-02 14:03:44

Edit: This will turn off all python warnings... So maybe having pygame specific warning categories would be a good idea.

In the meantime, in case someone finds this issue while searching for a way to hide the warnings:

  • -W ignore at the command line works (python3 -W ignore)
  • It's also possible to do it in the program:
import sys

if not sys.warnoptions:
    import warnings
    warnings.simplefilter("ignore")

That way, the warnings are off by default unless turned on with -W default


# # robertpfeiffer commented at 2020-10-03 07:42:10

Supporting vsync cross-platform is tricky, and even when you see no warning, it might not work. Do you think it should silently fail in all cases, even if vsync was requested explicitly but PyGame knows it could not be enabled?


# # lordmauve commented at 2020-10-03 09:55:37

Well, if we think people care if vsync was requested but is unavailable, then we should raise an exception.

Or we could treat everything that was passed to set_mode() as a hint and provide a function to query back what we actually got. This is probably the way forward because you don't necessarily even get the dimensions you requested.


# # robertpfeiffer commented at 2020-10-11 08:51:13

The difference is that vsync is a new parameter in pygame 2.0, so we can decide to throw an exception when it is incorrectly used with non-accelerated windows without breaking backward compatibility. If it were up to me, we'd also print warnings on other impossible flag combinations.

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

No branches or pull requests

2 participants