No hardware acceleration in a window?

SDL Development
1

Hello,

Sorry if this is old question, but am I correct in my impression
there is no way to use hardware accelerated blits to an SDL
surface in a window?

The SDL FAQ states this explicitely for DGA in X but seems
somewhat vague about the subject for other platforms such as
DirectX on win32. I’m not sure about DGA, but I’m believe
that DirectX allows hardware blitting in a window (from a
hardware shadow buffer), but I don’t seem to be able to access
this from SDL. I’m guessing this is an (unnecessary) limitation
imposed by SDL itself.

So…
Are there any plans to allow this in the forseeable future?
Or…
Have I missed some vital information somewhere?
Or…
Is there another way to implement tear free scrolling of
(all or part of) an SDL window?

Thanks for any advice–
Adrian Hey

2

Is there another way to implement tear free scrolling of
(all or part of) an SDL window?

Tear-free scrolling requires double-buffering I think. And that’s not
possible possible in a window.

3

Hello,

Sorry if this is old question, but am I correct in my impression
there is no way to use hardware accelerated blits to an SDL
surface in a window?

That depends on the platform and rendering target. DirectDraw can
accelerate blits into windows, so I guess SDL should be able to do it
as well.

If nothing else, glSDL does support fully accelerated and double
buffered rendering into windows if your OpenGl driver does. (And they
usually support both single and double buffered windows in my
experience, even on XFree86 where single buffering is not possible
normally.)

The SDL FAQ states this explicitely for DGA in X but seems
somewhat vague about the subject for other platforms such as
DirectX on win32.

It might actually depend on the driver. If the video card doesn’t
support h/w accelerated complex region clipping (for overlapping
windows), it has to be implemented in software, and I’m not sure
whether DirectDraw does that, or if it’s left to the drivers.

I’m not sure about DGA, but I’m believe
that DirectX allows hardware blitting in a window (from a
hardware shadow buffer), but I don’t seem to be able to access
this from SDL. I’m guessing this is an (unnecessary) limitation
imposed by SDL itself.

I suspect you have to use single buffering to get SDL to do this…

So…
Are there any plans to allow this in the forseeable future?

Dunno. There are subtle concistency issues with this, somewhat like
those I ran into with glSDL. SDL is pretty much designed around the
idea that there is a frame buffer that you can access directly, which
is not really what you get with an OpenGL display or window with
accelerated complex region clipping. This is real hard to get around
without changing the API, or entirely disabling some features.

Or…
Have I missed some vital information somewhere?

Well, I think the fact that windowed displays on commonly available
platforms are single buffered explains a great deal. There is no such
thing as a page flip operation, so you have to use a shadow buffer +
blitting to fake double buffering.

Or…
Is there another way to implement tear free scrolling of
(all or part of) an SDL window?

You need retrace sync for this, and it’s generally not possible to use
retrace sync on single buffered displays on any targets.

I think Mac OS X has a double buffered desktop, but that would be the
only mainstream OS that has one so far. Don’t know if SDL can take
advantage of it, though.

If you’re doing the shadow buffer thing with DirectDraw, you might
be able to get the back->front blit retrace synced with some drivers
(I think I’ve seen it work), but don’t count on it… I don’t know if
SDL even tries to do this, although IIRC, it does look like Kobo
Deluxe runs tearing free in windowed mode on some Windoze machines.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 08 April 2003 12.22, Adrian Hey wrote:

4

Is there another way to implement tear free scrolling of
(all or part of) an SDL window?

Tear-free scrolling requires double-buffering I think.

It is possible, but it requires very accurate timing of the rendering.
I’ve used a trick I call “half buffering” on Linux with custom
retrace sync code, and it works pretty well, except when the
scheduler decides my app is hogging too much on the CPU…

I never seem to get around to try the RTC driven non-busy waiting
retrace sync daemon approach. :frowning:

And that’s
not possible possible in a window.

Well, it is if you have a real time OS + scanline raster sync (can be
simulated), or a double buffered desktop… The latter is available
on high end Un*x workstations and AFAIK, on Mac OS X. I’ve heard
rumors about Microsoft working on a double buffered desktop as well,
but I don’t know if it’s available in any currently available OS.

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 08 April 2003 13.10, Olaf van der Spek wrote:

5

Hello David,

Thank you for your detailed reply.

If nothing else, glSDL does support fully accelerated and double
buffered rendering into windows if your OpenGl driver does. (And they
usually support both single and double buffered windows in my
experience, even on XFree86 where single buffering is not possible
normally.)

Thanks. I’ll try it.

I’m not sure about DGA, but I’m believe
that DirectX allows hardware blitting in a window (from a
hardware shadow buffer), but I don’t seem to be able to access
this from SDL. I’m guessing this is an (unnecessary) limitation
imposed by SDL itself.

I suspect you have to use single buffering to get SDL to do this…

You’re getting me confused now :slight_smile: Do you mean configure the
display surface for for single buffering and create a separate
hardware surface as a back buffer? I think that’s what you’re
suggesting below.

Have I missed some vital information somewhere?

Well, I think the fact that windowed displays on commonly available
platforms are single buffered explains a great deal. There is no such
thing as a page flip operation, so you have to use a shadow buffer +
blitting to fake double buffering.

Ah, thanks. I’ll try that too. I hadn’t realised the double buffer
flags only refer to hardware page flipping of an entire screen
(which is obviously not possible if the display surface is windowed).

Regards–
Adrian Hey

6

[…]

I’m not sure about DGA, but I’m believe
that DirectX allows hardware blitting in a window (from a
hardware shadow buffer), but I don’t seem to be able to access
this from SDL. I’m guessing this is an (unnecessary) limitation
imposed by SDL itself.

I suspect you have to use single buffering to get SDL to do
this…

You’re getting me confused now :slight_smile:

Well, I’m confusing myself… I’m not sure what I was thinking. :slight_smile:

AFAIK, SDL never allows you to blit directly into a window.
(Motivation below.)

BTW, glSDL does allow this if the OpenGL driver does, but that
probably means it can’t be 100% compatible with SDL. Might as well
kill that shortcut though, as it’s completely useless for anything
animated. You basically have to use double buffering with glSDL in
OpenGL mode, so it might as well be hardcoded.

Do you mean configure the
display surface for for single buffering and create a separate
hardware surface as a back buffer? I think that’s what you’re
suggesting below.

That might work, provided the target has accelerated h/w->h/w surface
blitting with complex region clipping. Might work with DirectX via
SDL, but I’ve never tried it.

However, this will be very slow if the back->front blits aren’t
accelerated. I suspect SDL doesn’t try this when “faking” double
buffering, and this would explain why.

What you normally get with SDL in windowed mode is a software back
surface. That is, you get “fake” double buffering (ie without h/w
page flipping) - and you get it whether you ask for double buffering
or not. (Due to the way overlapping windows are handled on most
desktops, exposing the actual display surface would break
applications that try to access the display surface directly, or blit
within or from it.)

Have I missed some vital information somewhere?

Well, I think the fact that windowed displays on commonly
available platforms are single buffered explains a great deal.
There is no such thing as a page flip operation, so you have to
use a shadow buffer + blitting to fake double buffering.

Ah, thanks. I’ll try that too. I hadn’t realised the double buffer
flags only refer to hardware page flipping of an entire screen
(which is obviously not possible if the display surface is
windowed).

Well, they don’t really, as SDL will use the “fake” (*) method (s/w
shadow surface) instead if you ask for double buffering and it can’t
be done the “real way”. You may get proper h/w pageflipping as an
extra bonus. You may also get a back->front software blit without
retrace sync when you flip.

(*) The reason for the quotation marks is that you do get
double buffering when you ask for it - although perhaps
not the kind you really want…

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 09 April 2003 10.14, Adrian Hey wrote: