When I do doublebuffering in SDL_FULLSCREEN, SDL_Flip() takes no time
whatsoever. In windowed mode, however, it takes 12-20ms, as measured by
SDL_GetTicks(). What causes this slowdown?
Flip in fullscreen mode just changes a single pointer in the video card. In
windowed mode, Flip has to copy the entire contents of the backbuffer to the
screen.
-Jesse> ----- Original Message -----
From: tsm@accesscomm.ca (Tyler Montbriand)
To:
Sent: Thursday, August 30, 2001 7:37 PM
Subject: [SDL] Double buffering in windowed and fullscreen modesWhen I do doublebuffering in SDL_FULLSCREEN, SDL_Flip() takes no time
whatsoever. In windowed mode, however, it takes 12-20ms, as measured by
SDL_GetTicks(). What causes this slowdown?
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hardware flipping in fullscreen and software flipping in windowed
maybe ? What graphics card do you have ?On Friday 31. August 2001 02:37, you wrote:
When I do doublebuffering in SDL_FULLSCREEN, SDL_Flip() takes no
time whatsoever. In windowed mode, however, it takes 12-20ms, as
measured by SDL_GetTicks(). What causes this slowdown?
–
Trick
When I do doublebuffering in SDL_FULLSCREEN, SDL_Flip() takes no time
whatsoever. In windowed mode, however, it takes 12-20ms, as measured
by
SDL_GetTicks(). What causes this slowdown?
In fullscreen mode, SDL can just tell the videocard to read from the
other screen buffer. So it’s just a case of changing a pointer or two.
In windowed mode, a flip probably has to copy the data from the back
buffer to the relevant part of the main video memory, so this would be
somewhat similar to the speed of a Blit.–
Ben Sizer
Trick wrote:> On Friday 31. August 2001 02:37, you wrote:
When I do doublebuffering in SDL_FULLSCREEN, SDL_Flip() takes no
time whatsoever. In windowed mode, however, it takes 12-20ms, as
measured by SDL_GetTicks(). What causes this slowdown?Hardware flipping in fullscreen and software flipping in windowed
maybe ? What graphics card do you have ?
I’ve got a Geforce256. I can understand some slowdown, but 12ms?
That’s horrible!
“Tyler Montbriand” wrote
I’ve got a Geforce256. I can understand some slowdown, but 12ms?
That’s horrible!
i’m guessing you’re running windows? in any event SDL doesn’t
do hardware surfaces for windowed displays. :[
what resolution are you running at?
Trick wrote:
When I do doublebuffering in SDL_FULLSCREEN, SDL_Flip() takes no
time whatsoever. In windowed mode, however, it takes 12-20ms, as
measured by SDL_GetTicks(). What causes this slowdown?Hardware flipping in fullscreen and software flipping in windowed
maybe ? What graphics card do you have ?I’ve got a Geforce256. I can understand some slowdown, but 12ms?
That’s horrible!
Well, yes, 12 ms is horrible. Sounds like it’s the CPU that has to do
the transfer, as is normally the case on Linux. AFAIK, Windows should
support DMA transfers, but either I’m wrong, or something in your setup
is…
Well, unless, of course, you’re running at 1280x1024, 32 bit. 
Such a
buffer takes a minimum of 10 ms to transfer over AGP 1x, if everything is
theoretically perfect. (Which is never the case in real life…)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 31 August 2001 03:16, Tyler Montbriand wrote:
On Friday 31. August 2001 02:37, you wrote:
Pete Shinners wrote:
i’m guessing you’re running windows? in any event SDL doesn’t
do hardware surfaces for windowed displays. :[
what resolution are you running at?
No hardware acceleration for windowed surfaces? Will this be fixed in
SDL1.3?
128096016bpp, though the res doesn’t seem to matter; windowed, I
always get a uniformly bad 50fps. At fullscreen it maxes out at my
monitor’s refresh rate of 85Hz, even though each SDL_FillRect() takes a
full two milliseconds for some reason. SDL claims that colorfills are
hardware accelerated with my card, yet…
Pete Shinners wrote:
i’m guessing you’re running windows? in any event SDL doesn’t
do hardware surfaces for windowed displays. :[
what resolution are you running at?No hardware acceleration for windowed surfaces? Will this be fixed in
SDL1.3?
AFAIK, no. Windows doesn’t support it - and cannot, without hardware
based clipping. DirectX allows you to blit to the “screen” surface of a
window and does clipping internally, but if you were allowed to lock the
surface and access VRAM directly, you’d have to deal with clipping
yourself not to overdraw other windows, mouse pointer (unless it’s a
hardware sprite), menues etc.
128096016bpp, though the res doesn’t seem to matter; windowed, I
always get a uniformly bad 50fps.
Weird… Does it make a difference if you use SDL_UpdateRect() for a
(very) small region of your window?
At fullscreen it maxes out at my
monitor’s refresh rate of 85Hz,
Sounds reasonable.
even though each SDL_FillRect() takes a
full two milliseconds for some reason.
Any rectangle size, or for the whole screen? (In the latter case, you’re
getting just about the expected performance, I think. Quite OK, I’d say.)
SDL claims that colorfills are
hardware accelerated with my card, yet…
Hmm… Are you doing alpha blending or something?
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 31 August 2001 17:28, Tyler Montbriand wrote:
No hardware acceleration for windowed surfaces? Will this be fixed in
SDL1.3?AFAIK, no. Windows doesn’t support it - and cannot, without hardware
based clipping. DirectX allows you to blit to the “screen” surface of a
window and does clipping internally, but if you were allowed to lock the
surface and access VRAM directly, you’d have to deal with clipping
yourself not to overdraw other windows, mouse pointer (unless it’s a
hardware sprite), menues etc.
actually, with directx you get great hardware support
for windows. this shouldn’t be too surprising, after all
you can also get accelerated and doublebuffered opengl
windows.
directdraw does provide you with hardware clipping controls,
when you create a hardware accelerated directx window, you
also create a hardware clipper, that you let windows
control for you. if you don’t create that clipper you
overwrite other windows on the screen. since you let windows
take control of the clipper, you really don’t need to mess
with it, although it looks like you can if you want to do
your own special clipping.
i’ve always thought the reason there was no support for
hardware acceleration for windows was you run into more
frequent problems with windows “losing” your surfaces?
but i’ve never really been sure.
“David Olofson” <david.olofson at reologica.se> wrote in message
news:mailman.999276066.6350.sdl at libsdl.org…> On Friday 31 August 2001 17:28, Tyler Montbriand wrote:
Pete Shinners wrote:
i’m guessing you’re running windows? in any event SDL doesn’t
do hardware surfaces for windowed displays. :[
what resolution are you running at?No hardware acceleration for windowed surfaces? Will this be fixed in
SDL1.3?AFAIK, no. Windows doesn’t support it - and cannot, without hardware
based clipping. DirectX allows you to blit to the “screen” surface of a
window and does clipping internally, but if you were allowed to lock the
surface and access VRAM directly, you’d have to deal with clipping
yourself not to overdraw other windows, mouse pointer (unless it’s a
hardware sprite), menues etc.
This should not really be a problem. Just create a virtual screen surface
in video memory (similar to what ‘SDL_DOUBLEBUF’ and ‘SDL_SWSURFACE’ already
do), and do the clipping in ‘SDL_Flip’ or ‘SDL_UpdateRect’.
–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
I believe the windowed acceleration issue is more of a driver/setup issue
than anything with SDL.> ----- Original Message -----
From: sdl-admin@libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Tyler Montbriand
Sent: Friday, August 31, 2001 11:29 AM
To: sdl at libsdl.org
Subject: Re: [SDL] Double buffering in windowed and fullscreen modesPete Shinners wrote:
i’m guessing you’re running windows? in any event SDL doesn’t
do hardware surfaces for windowed displays. :[
what resolution are you running at?No hardware acceleration for windowed surfaces? Will this be fixed in
SDL1.3?128096016bpp, though the res doesn’t seem to matter; windowed, I
always get a uniformly bad 50fps. At fullscreen it maxes out at my
monitor’s refresh rate of 85Hz, even though each SDL_FillRect() takes a
full two milliseconds for some reason. SDL claims that colorfills are
hardware accelerated with my card, yet…
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl