Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
FULLSCREEN and DOUBLEBUF
142 views
Skip to first unread message
Paul St George
Jun 7, 2018, 1:11:12 PM6/7/18
to
This is both a narrow question about some code and a more general
question about syntax in Python
Using the Pygame modules, I want to set both FULLSCREEN and DOUBLEBUF
I can use
screen =
pygame.display.set_mode((screen_width,screen_height),pygame.FULLSCREEN)
to set a FULLSCREEN display
Or, I can use
screen =
pygame.display.set_mode((screen_width,screen_height),pygame.DOUBLEBUF)
to set DOUBLEBUF
But how do I set both FULLSCREEN and DOUBLEBUF?
And, how can I test or check that DOUBLEBUF is set?
--
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com
question about syntax in Python
Using the Pygame modules, I want to set both FULLSCREEN and DOUBLEBUF
I can use
screen =
pygame.display.set_mode((screen_width,screen_height),pygame.FULLSCREEN)
to set a FULLSCREEN display
Or, I can use
screen =
pygame.display.set_mode((screen_width,screen_height),pygame.DOUBLEBUF)
to set DOUBLEBUF
But how do I set both FULLSCREEN and DOUBLEBUF?
And, how can I test or check that DOUBLEBUF is set?
--
Paul St George
http://www.paulstgeorge.com
http://www.devices-of-wonder.com
Chris Angelico
Jun 7, 2018, 1:57:10 PM6/7/18
to
On Fri, Jun 8, 2018 at 3:12 AM, Paul St George <em...@paulstgeorge.com> wrote:
> This is both a narrow question about some code and a more general question
> about syntax in Python
>
> Using the Pygame modules, I want to set both FULLSCREEN and DOUBLEBUF
>
> I can use
> screen =
> pygame.display.set_mode((screen_width,screen_height),pygame.FULLSCREEN)
> to set a FULLSCREEN display
>
> Or, I can use
> screen =
> pygame.display.set_mode((screen_width,screen_height),pygame.DOUBLEBUF)
> to set DOUBLEBUF
>
> But how do I set both FULLSCREEN and DOUBLEBUF?
>
> And, how can I test or check that DOUBLEBUF is set?
This is definitely a pygame question. So let's grab the docos for that
> This is both a narrow question about some code and a more general question
> about syntax in Python
>
> Using the Pygame modules, I want to set both FULLSCREEN and DOUBLEBUF
>
> I can use
> screen =
> pygame.display.set_mode((screen_width,screen_height),pygame.FULLSCREEN)
> to set a FULLSCREEN display
>
> Or, I can use
> screen =
> pygame.display.set_mode((screen_width,screen_height),pygame.DOUBLEBUF)
> to set DOUBLEBUF
>
> But how do I set both FULLSCREEN and DOUBLEBUF?
>
> And, how can I test or check that DOUBLEBUF is set?
set_mode function.
https://www.pygame.org/docs/ref/display.html#pygame.display.set_mode
You're passing two parameters in each of your examples. The first is a
tuple of (w,h) for the dimensions; the second is a constant for the
mode you want. The name of the second argument is "flags", according
to the documentation. That usually means that you can provide
multiple. The exact mechanism for combining flags is given in the last
paragraph of the docs. I'll let you take the credit for figuring out
the details yourself :)
ChrisA
Mark Lawrence
Jun 7, 2018, 3:18:01 PM6/7/18
to
On 07/06/18 18:12, Paul St George wrote:
> This is both a narrow question about some code and a more general
> question about syntax in Python
>
> Using the Pygame modules, I want to set both FULLSCREEN and DOUBLEBUF
>
> I can use
> screen =
> pygame.display.set_mode((screen_width,screen_height),pygame.FULLSCREEN)
> to set a FULLSCREEN display
>
> Or, I can use
> screen =
> pygame.display.set_mode((screen_width,screen_height),pygame.DOUBLEBUF)
> to set DOUBLEBUF
>
> But how do I set both FULLSCREEN and DOUBLEBUF?
>
> And, how can I test or check that DOUBLEBUF is set?
>
Pure guesswork but how about:-
> This is both a narrow question about some code and a more general
> question about syntax in Python
>
> Using the Pygame modules, I want to set both FULLSCREEN and DOUBLEBUF
>
> I can use
> screen =
> pygame.display.set_mode((screen_width,screen_height),pygame.FULLSCREEN)
> to set a FULLSCREEN display
>
> Or, I can use
> screen =
> pygame.display.set_mode((screen_width,screen_height),pygame.DOUBLEBUF)
> to set DOUBLEBUF
>
> But how do I set both FULLSCREEN and DOUBLEBUF?
>
> And, how can I test or check that DOUBLEBUF is set?
>
screen = pygame.display.set_mode((screen_width,screen_height),
pygame.FULLSCREEN | pygame.DOUBLEBUF)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
Paul St George
Jun 8, 2018, 3:59:28 AM6/8/18
to
Excellent. Now I know what to do in this instance and I understand the
principle.
I hesitantly tried this:
screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
pygame.DOUBLEBUF)
Hesitantly because I expected the *bitwise or operator* (|) to work like
a toggle, so FULLSCREEN or DOUBLEBUF.
No errors were reported, but how would I check that DOUBLEBUF had been
set? Is there a general rule, such as replace 'set_something' with
'get_something'?
Paul St George
On 07/06/2018 19:56, Chris Angelico wrote:
principle.
I hesitantly tried this:
screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
pygame.DOUBLEBUF)
Hesitantly because I expected the *bitwise or operator* (|) to work like
a toggle, so FULLSCREEN or DOUBLEBUF.
No errors were reported, but how would I check that DOUBLEBUF had been
set? Is there a general rule, such as replace 'set_something' with
'get_something'?
Paul St George
On 07/06/2018 19:56, Chris Angelico wrote:
> On Fri, Jun 8, 2018 at 3:12 AM, Paul St George <em...@paulstgeorge.com> wrote:
>> This is both a narrow question about some code and a more general question
>> about syntax in Python
>>
>> Using the Pygame modules, I want to set both FULLSCREEN and DOUBLEBUF
>>
>> I can use
>> screen =
>> pygame.display.set_mode((screen_width,screen_height),pygame.FULLSCREEN)
>> to set a FULLSCREEN display
>>
>> Or, I can use
>> screen =
>> pygame.display.set_mode((screen_width,screen_height),pygame.DOUBLEBUF)
>> to set DOUBLEBUF
>>
>> But how do I set both FULLSCREEN and DOUBLEBUF?
>>
>> And, how can I test or check that DOUBLEBUF is set?
>> This is both a narrow question about some code and a more general question
>> about syntax in Python
>>
>> Using the Pygame modules, I want to set both FULLSCREEN and DOUBLEBUF
>>
>> I can use
>> screen =
>> pygame.display.set_mode((screen_width,screen_height),pygame.FULLSCREEN)
>> to set a FULLSCREEN display
>>
>> Or, I can use
>> screen =
>> pygame.display.set_mode((screen_width,screen_height),pygame.DOUBLEBUF)
>> to set DOUBLEBUF
>>
>> But how do I set both FULLSCREEN and DOUBLEBUF?
>>
>> And, how can I test or check that DOUBLEBUF is set?
> This is definitely a pygame question. So let's grab the docos for that
> set_mode function.
>
> https://www.pygame.org/docs/ref/display.html#pygame.display.set_mode
>
> You're passing two parameters in each of your examples. The first is a
> tuple of (w,h) for the dimensions; the second is a constant for the
> mode you want. The name of the second argument is "flags", according
> to the documentation. That usually means that you can provide
> multiple. The exact mechanism for combining flags is given in the last
> paragraph of the docs. I'll let you take the credit for figuring out
> the details yourself :)
>
> ChrisA
>
+44(0)7595 37 1302
> set_mode function.
>
> https://www.pygame.org/docs/ref/display.html#pygame.display.set_mode
>
> You're passing two parameters in each of your examples. The first is a
> tuple of (w,h) for the dimensions; the second is a constant for the
> mode you want. The name of the second argument is "flags", according
> to the documentation. That usually means that you can provide
> multiple. The exact mechanism for combining flags is given in the last
> paragraph of the docs. I'll let you take the credit for figuring out
> the details yourself :)
>
> ChrisA
>
Rhodri James
Jun 8, 2018, 7:24:26 AM6/8/18
to
On 08/06/18 09:00, Paul St George wrote:
> Excellent. Now I know what to do in this instance and I understand the
> principle.
>
> I hesitantly tried this:
>
> screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
> pygame.DOUBLEBUF)
>
> Hesitantly because I expected the *bitwise or operator* (|) to work like
> a toggle, so FULLSCREEN or DOUBLEBUF.
The bitwise OR operator peforms a bitwise OR, i.e. *both* flags get set.
> Excellent. Now I know what to do in this instance and I understand the
> principle.
>
> I hesitantly tried this:
>
> screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
> pygame.DOUBLEBUF)
>
> Hesitantly because I expected the *bitwise or operator* (|) to work like
> a toggle, so FULLSCREEN or DOUBLEBUF.
> No errors were reported, but how would I check that DOUBLEBUF had been
> set? Is there a general rule, such as replace 'set_something' with
> 'get_something'?
pygame.display.set_mode() tells you that you get a Surface out of it.
Reaching for the docs for that, this leaps out:
https://www.pygame.org/docs/ref/surface.html#pygame.Surface.get_flags
PS: it's generally considered polite not to top post on this mailing list.
--
Rhodri James *-* Kynesim Ltd
Darren Pardoe
Jun 8, 2018, 7:41:49 AM6/8/18
to
I have always top posted even though most editors start with the cursor at the bottom. Is there any foundation to this methodology as my logic suggest we top post?
MRAB
Jun 8, 2018, 10:29:52 AM6/8/18
to
interleaved style with trimming of unwanted text worked best in practice.
Many years later, when the internet and World Wide Web gained widespread
usage, people weren't told about what had been found to work best, and
the email programs they used created a reply that quoted the original
message and left the cursor at the top, so people just put their reply
there.
Rhodri James
Jun 8, 2018, 12:15:34 PM6/8/18
to
practicality nicely:
A: Because it reverses the order of the conversation
Q: Why is top posting unhelpful?
Paul St George
Jun 9, 2018, 3:30:21 PM6/9/18
to
> On 08/06/18 09:00, Paul St George wrote:
>> Excellent. Now I know what to do in this instance and I understand
>> the principle.
>>
>> I hesitantly tried this:
>>
>> screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
>> pygame.DOUBLEBUF)
>>
>> Hesitantly because I expected the *bitwise or operator* (|) to work
>> like a toggle, so FULLSCREEN or DOUBLEBUF.
>
>> the principle.
>>
>> I hesitantly tried this:
>>
>> screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
>> pygame.DOUBLEBUF)
>>
>> Hesitantly because I expected the *bitwise or operator* (|) to work
>> like a toggle, so FULLSCREEN or DOUBLEBUF.
>
On 08/06/2018 12:52, Rhodri James wrote:
> The bitwise OR operator peforms a bitwise OR, i.e. *both* flags get set.
>
>> No errors were reported, but how would I check that DOUBLEBUF had
>> been set? Is there a general rule, such as replace 'set_something'
>> with 'get_something'?
>
> There's documentation. The link Chris gave you for
> pygame.display.set_mode() tells you that you get a Surface out of it.
> Reaching for the docs for that, this leaps out:
>
> https://www.pygame.org/docs/ref/surface.html#pygame.Surface.get_flags
>
>
So...
> The bitwise OR operator peforms a bitwise OR, i.e. *both* flags get set.
>
>> No errors were reported, but how would I check that DOUBLEBUF had
>> been set? Is there a general rule, such as replace 'set_something'
>> with 'get_something'?
>
> There's documentation. The link Chris gave you for
> pygame.display.set_mode() tells you that you get a Surface out of it.
> Reaching for the docs for that, this leaps out:
>
> https://www.pygame.org/docs/ref/surface.html#pygame.Surface.get_flags
>
>
print pygame.display.get_surface()
gives
<Surface(720x480x32 SW)>
and
print screen.get_flags()
gives
-2147483648
The lists of flags at
<https://www.pygame.org/docs/ref/surface.html#pygame.Surface.get_flags>
and <http://www.rpi.edu/dept/acm/packages/SDL/1.2.6/include/SDL/SDL_video.h>
has nothing remotely like -2147483648. I would expect something more
like 0x40000000
Am I using the wrong code to determine whether I have successfully set
DOUBLEBUF with
screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
pygame.DOUBLEBUF)
What does -2147483648 tell me? Does this number need converting?
>
>
>
Richard Damon
Jun 9, 2018, 4:04:04 PM6/9/18
to
On 6/9/18 3:31 PM, Paul St George wrote:
> So...
>
> print pygame.display.get_surface()
> gives
> <Surface(720x480x32 SW)>
>
> and
> print screen.get_flags()
> gives
> -2147483648
>
> The lists of flags at
> <https://www.pygame.org/docs/ref/surface.html#pygame.Surface.get_flags>
> and
> <http://www.rpi.edu/dept/acm/packages/SDL/1.2.6/include/SDL/SDL_video.h>
>
> has nothing remotely like -2147483648. I would expect something more
> like 0x40000000
>
> Am I using the wrong code to determine whether I have successfully set
> DOUBLEBUF with
>
> screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
> pygame.DOUBLEBUF)
>
> AND
>
> What does -2147483648 tell me? Does this number need converting?
That number is printed in Decimal, the listing gives it in hex. If you
> So...
>
> print pygame.display.get_surface()
> gives
> <Surface(720x480x32 SW)>
>
> and
> print screen.get_flags()
> gives
> -2147483648
>
> The lists of flags at
> <https://www.pygame.org/docs/ref/surface.html#pygame.Surface.get_flags>
> and
> <http://www.rpi.edu/dept/acm/packages/SDL/1.2.6/include/SDL/SDL_video.h>
>
> has nothing remotely like -2147483648. I would expect something more
> like 0x40000000
>
> Am I using the wrong code to determine whether I have successfully set
> DOUBLEBUF with
>
> screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
> pygame.DOUBLEBUF)
>
> AND
>
> What does -2147483648 tell me? Does this number need converting?
convert the number to hex you get
0x80000000
--
Richard Damon
Mark Lawrence
Jun 10, 2018, 12:39:48 AM6/10/18
to
On 09/06/18 20:31, Paul St George wrote:
>
> print pygame.display.get_surface()
> gives
> <Surface(720x480x32 SW)>
>
> and
> print screen.get_flags()
> gives
> -2147483648
>
> The lists of flags at
> <https://www.pygame.org/docs/ref/surface.html#pygame.Surface.get_flags>
> and
> <http://www.rpi.edu/dept/acm/packages/SDL/1.2.6/include/SDL/SDL_video.h>
>
> has nothing remotely like -2147483648. I would expect something more
> like 0x40000000
>
> Am I using the wrong code to determine whether I have successfully set
> DOUBLEBUF with
>
> screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
> pygame.DOUBLEBUF)
>
> AND
>
> What does -2147483648 tell me? Does this number need converting?
>>
From the interactive interpreter:-
>
> print pygame.display.get_surface()
> gives
> <Surface(720x480x32 SW)>
>
> and
> print screen.get_flags()
> gives
> -2147483648
>
> The lists of flags at
> <https://www.pygame.org/docs/ref/surface.html#pygame.Surface.get_flags>
> and
> <http://www.rpi.edu/dept/acm/packages/SDL/1.2.6/include/SDL/SDL_video.h>
>
> has nothing remotely like -2147483648. I would expect something more
> like 0x40000000
>
> Am I using the wrong code to determine whether I have successfully set
> DOUBLEBUF with
>
> screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN |
> pygame.DOUBLEBUF)
>
> AND
>
> What does -2147483648 tell me? Does this number need converting?
>>
>>> hex(-2147483648)
'-0x80000000'
>>> hex(pygame.FULLSCREEN)
'-0x80000000'
>>> hex(pygame.DOUBLEBUF)
'0x40000000'
Paul St George
Jun 10, 2018, 7:14:22 AM6/10/18
to
To recap: this thread started with a question. How do I know whether
DOUBLEBUF has been set with:
screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF |
pygame.FULLSCREEN)
Thanks go to Mark Lawrence and Richard Damon.
Using
print hex(screen.get_flags())
I can see that the order of the two flags does not make a difference.
screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF | pygame.FULLSCREEN)
print hex(screen.get_flags())
'-0x80000000'
BUT
omitting DOUBLEBUF from the code
screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN)
also makes no difference to the report
print hex(screen.get_flags())
'-0x80000000'
AND
with with only DOUBLEBUF in the code
screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF)
does not give the expected and desired '-0x40000000'
instead, the report is
print hex(screen.get_flags())
‘0x0’
0x0 (SWSURFACE) is consistent with
print pygame.display.get_surface()
‘<Surface(720x480x32 SW)>’
It seems that DOUBLEBUF is *not* being set. I am guessing this is because the arguments passed by pygame.display.set_mode() are only requests. The actual display will depend on the system, and what is available/possible.
More guessing leads me to wonder whether DOUBLEBUF is only available when HWSURFACE is being used so I tried three flags with:
flags = pygame.FULLSCREEN | pygame.DOUBLEBUF | pygame.HWSURFACE
screen = pygame.display.set_mode((0, 0), flags)
But no change (screen is still SW and DOUBLEBUF is not set):
print pygame.display.get_surface()
<Surface(720x480x32 SW)>
print hex(screen.get_flags())
-0x80000000
QUESTIONS
Can anyone find an error in any of this? I hope so.
Is DOUBLEBUF dependent on HWSURFACE?
If so, how does one force the change to a Hardware surface? ‘set_mode’ is not doing it.
DOUBLEBUF has been set with:
screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF |
pygame.FULLSCREEN)
Using
print hex(screen.get_flags())
I can see that the order of the two flags does not make a difference.
screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF | pygame.FULLSCREEN)
screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN | pygame.DOUBLEBUF)
both report the same
print hex(screen.get_flags())
'-0x80000000'
BUT
omitting DOUBLEBUF from the code
screen = pygame.display.set_mode((720,480), pygame.FULLSCREEN)
also makes no difference to the report
print hex(screen.get_flags())
'-0x80000000'
AND
with with only DOUBLEBUF in the code
screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF)
does not give the expected and desired '-0x40000000'
instead, the report is
print hex(screen.get_flags())
‘0x0’
0x0 (SWSURFACE) is consistent with
print pygame.display.get_surface()
‘<Surface(720x480x32 SW)>’
It seems that DOUBLEBUF is *not* being set. I am guessing this is because the arguments passed by pygame.display.set_mode() are only requests. The actual display will depend on the system, and what is available/possible.
More guessing leads me to wonder whether DOUBLEBUF is only available when HWSURFACE is being used so I tried three flags with:
flags = pygame.FULLSCREEN | pygame.DOUBLEBUF | pygame.HWSURFACE
screen = pygame.display.set_mode((0, 0), flags)
But no change (screen is still SW and DOUBLEBUF is not set):
print pygame.display.get_surface()
<Surface(720x480x32 SW)>
print hex(screen.get_flags())
-0x80000000
QUESTIONS
Can anyone find an error in any of this? I hope so.
Is DOUBLEBUF dependent on HWSURFACE?
If so, how does one force the change to a Hardware surface? ‘set_mode’ is not doing it.
Peter Otten
Jun 10, 2018, 10:39:22 AM6/10/18
to
Paul St George wrote:
> So...
>
> So...
>
> print pygame.display.get_surface()
> gives
> <Surface(720x480x32 SW)>
>
> and
> print screen.get_flags()
> gives
> -2147483648
> gives
> <Surface(720x480x32 SW)>
>
> and
> print screen.get_flags()
> gives
> -2147483648
> To recap: this thread started with a question. How do I know whether
> DOUBLEBUF has been set with:
>
> screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF |
> pygame.FULLSCREEN)
flags = screen.get_flags()
> DOUBLEBUF has been set with:
>
> screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF |
> pygame.FULLSCREEN)
if flags & pygame.DOUBLEBUF:
print("DOUBLEBUF has been set")
if flags & pygame.FULLSCREEN:
print("FULLSCREEN has been set")
See the pattern?
The easiest way to argue about flags is in binary notation. Every flag
corresponds to an integer with a single bit set, e. g.
HOT = 0b001
BLUE = 0b010
RIGHTEOUS = 0b100
You can combine the flags with bitwise or
hot_and_righteous = HOT | RIGHTEOUS # 0b101
and query them with bitwise and:
>>> if hot_and_righteous & HOT: print("hot")
...
hot
>>> if hot_and_righteous & BLUE: print("blue")
...
>>> if hot_and_righteous & RIGHTEOUS: print("righteous")
...
righteous
With your actual pygame flags it's very much the same. However, because
integers in Python are signed numbers like
-2147483648
may be puzzling, even when you display them in binary
>>> bin(-2147483648)
'-0b10000000000000000000000000000000'
You might think that only one flag is set because there is only one 1, but
the - sign corresponds to an "infinite" number of leading 1s.
If you know that the flags are stored (for example) in a 32bit integer you
can mask off these leading 1s and see the actual data more clearly:
>>> bin(-2147483648 & 0b11111111111111111111111111111111)
'0b10000000000000000000000000000000'
OK, so in this case it probably* was a single flag, but that's not always
the case:
>>> bin(-7)
'-0b111'
>>> bin(-7 & 0b11111111111111111111111111111111)
'0b11111111111111111111111111111001'
(*) What if the flags were stored in a 64bit integer?
Paul St George
Jun 10, 2018, 1:43:54 PM6/10/18
to
> Paul St George wrote:
>
>> So...
>>
>> print pygame.display.get_surface()
>> gives
>> <Surface(720x480x32 SW)>
>>
>> and
>> print screen.get_flags()
>> gives
>> -2147483648
>> To recap: this thread started with a question. How do I know whether
>> DOUBLEBUF has been set with:
>>
>> screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF |
>> pygame.FULLSCREEN)
>
>> So...
>>
>> print pygame.display.get_surface()
>> gives
>> <Surface(720x480x32 SW)>
>>
>> and
>> print screen.get_flags()
>> gives
>> -2147483648
>> To recap: this thread started with a question. How do I know whether
>> DOUBLEBUF has been set with:
>>
>> screen = pygame.display.set_mode((720,480), pygame.DOUBLEBUF |
>> pygame.FULLSCREEN)
On 10/06/2018 16:38, Peter Otten wrote:
> flags = screen.get_flags()
> if flags & pygame.DOUBLEBUF:
> print("DOUBLEBUF has been set")
> if flags & pygame.FULLSCREEN:
> print("FULLSCREEN has been set")
>
> See the pattern?
I do. I do. And also, I now know for certain that DOUBLEBUF is not being
> flags = screen.get_flags()
> if flags & pygame.DOUBLEBUF:
> print("DOUBLEBUF has been set")
> if flags & pygame.FULLSCREEN:
> print("FULLSCREEN has been set")
>
> See the pattern?
set.
The insights about flags will take more time to digest. Thank you for both!
Gregory Ewing
Jun 10, 2018, 7:48:10 PM6/10/18
to
Dennis Lee Bieber wrote:
> Both may be dependent upon the actual hardware graphics board and the
> drivers for said board.
My guess is that if your surface is not fullscreen or is not
a hardware surface, then you're always drawing into an ofscreen
buffer that gets copied to the screen when display.flip() is
called. In other words, it's effectively double-buffered
whether you request it or not.
The only time it's an issue is when you're drawing directly
to the screen memory, i.e. both FULLSCREEN and HWSURFACE
where your hardware and drivers support that.
My suggestion is to just always specify DOUBLEBUF and not
worry about what's going on behind the scenes. That will
almost always give the result you want, i.e. a flicker-free
display.
The only time it would be an issue is if you wanted your
surface to *not* be double-buffered for some reason, but
that would be a rare situation.
--
Greg
> Both may be dependent upon the actual hardware graphics board and the
> drivers for said board.
My guess is that if your surface is not fullscreen or is not
a hardware surface, then you're always drawing into an ofscreen
buffer that gets copied to the screen when display.flip() is
called. In other words, it's effectively double-buffered
whether you request it or not.
The only time it's an issue is when you're drawing directly
to the screen memory, i.e. both FULLSCREEN and HWSURFACE
where your hardware and drivers support that.
My suggestion is to just always specify DOUBLEBUF and not
worry about what's going on behind the scenes. That will
almost always give the result you want, i.e. a flicker-free
display.
The only time it would be an issue is if you wanted your
surface to *not* be double-buffered for some reason, but
that would be a rare situation.
--
Greg
Paul St George
Jun 12, 2018, 12:56:40 PM6/12/18
to
> Dennis Lee Bieber wrote:
>> Both may be dependent upon the actual hardware graphics board and
>> the
>> drivers for said board.
> On 11/06/2018 01:47, Gregory Ewing wrote:
> My guess is that if your surface is not fullscreen or is not
> a hardware surface, then you're always drawing into an ofscreen
> buffer that gets copied to the screen when display.flip() is
> called. In other words, it's effectively double-buffered
> whether you request it or not.
>
> The only time it's an issue is when you're drawing directly
> to the screen memory, i.e. both FULLSCREEN and HWSURFACE
> where your hardware and drivers support that.
>
> My suggestion is to just always specify DOUBLEBUF and not
> worry about what's going on behind the scenes. That will
> almost always give the result you want, i.e. a flicker-free
> display.
>
> The only time it would be an issue is if you wanted your
> surface to *not* be double-buffered for some reason, but
> that would be a rare situation.
>
Thank you! Your intervention could not have been more timely. I was just
> My guess is that if your surface is not fullscreen or is not
> a hardware surface, then you're always drawing into an ofscreen
> buffer that gets copied to the screen when display.flip() is
> called. In other words, it's effectively double-buffered
> whether you request it or not.
>
> The only time it's an issue is when you're drawing directly
> to the screen memory, i.e. both FULLSCREEN and HWSURFACE
> where your hardware and drivers support that.
>
> My suggestion is to just always specify DOUBLEBUF and not
> worry about what's going on behind the scenes. That will
> almost always give the result you want, i.e. a flicker-free
> display.
>
> The only time it would be an issue is if you wanted your
> surface to *not* be double-buffered for some reason, but
> that would be a rare situation.
>
about to throw away the screen and try again with another. I want to use
display.flip() and thought that was dependent on being able to set
DOUBLEBUF. The surface is fullscreen.
I had considered meddling with the config.txt to try to enable*
HWSURFACE but from what you say, this is unnecessary. Have I understood
you right?
Paul
* Perhaps by uncommenting #dtparam=spi=on
Greg Ewing
Jun 12, 2018, 7:26:50 PM6/12/18
to
Paul St George wrote:
> I had considered meddling with the config.txt to try to enable*
> HWSURFACE but from what you say, this is unnecessary.
I don't really have much idea what effect HWSURFACE would have,
> I had considered meddling with the config.txt to try to enable*
> HWSURFACE but from what you say, this is unnecessary.
if any. It will certainly depend a lot on your hardware and
drivers.
My suggestion would be not to bother with it unless you're
having performance issues, and then try it to see if it
makes any difference.
Note that it's conceivable that HWSURFACE could actually
make things slower in some situations, e.g. if it results
in more movement of data between main memory and video
memory. Experimentation is the only way to be sure.
--
Greg
0 new messages