SDL_GetVideoInfo strangeness

In Mac OS X with the Quartz driver, all flags returned by
SDL_GetVideoInfo() are always 0. This is obviously incorrect, can
someone familiar with SDL’s Quartz driver comment on this?

(OS X 10.3.1, SDL 1.2.6)

I suppose the wm_available should be set to 1, but otherwise the flags
should be zero since there is no hardware surface support in Mac OS X
(besides OpenGL, of course).

An OpenGL backend for SDL would be difficult to manage (perhaps
impossible), since OpenGL doesn’t allow direct (pointer) access to the
framebuffer. To test a pixel in the framebuffer, you have to copy it to
system memory first, which can be quite slow.

An OpenGL frontend is another story - this can work very well, and many
people have done it.On Nov 29, 2003, at 3:02 PM, sdl-request at libsdl.org wrote:

Message: 4
To: sdl at libsdl.org
From: John Philip
Date: Fri, 28 Nov 2003 19:46:59 -0500
Subject: [SDL] SDL_GetVideoInfo strangeness
Reply-To: sdl at libsdl.org

In Mac OS X with the Quartz driver, all flags returned by
SDL_GetVideoInfo() are always 0. This is obviously incorrect, can
someone familiar with SDL’s Quartz driver comment on this?

(OS X 10.3.1, SDL 1.2.6)

On my Mac OS X system, calling SDL_SetVideoMode(SDL_HWSURFACE |
SDL_FULLSCREEN | SDL_DOUBLEBUF) results in a surface with the following
flags:
SDL_HWSURFACE
SDL_NOFRAME
SDL_PREALLOC
SDL_DOUBLEBUF
SDL_FULLSCREEN

This SDL_Surface for the screen claims to be a hardware surface, is it
really? If so, SDL_GetVideoInfo() should be returning hw_available =
true, and probably some other fields true as well.On Nov 29, 2003, at 7:15 PM, Darrell Walisser wrote:

I suppose the wm_available should be set to 1, but otherwise the flags
should be zero since there is no hardware surface support in Mac OS X
(besides OpenGL, of course).

An OpenGL backend for SDL would be difficult to manage (perhaps
impossible), since OpenGL doesn’t allow direct (pointer) access to the
framebuffer. To test a pixel in the framebuffer, you have to copy it
to system memory first, which can be quite slow.

An OpenGL frontend is another story - this can work very well, and
many people have done it.

On Nov 29, 2003, at 3:02 PM, sdl-request at libsdl.org wrote:

Message: 4
To: sdl at libsdl.org
From: John Philip <@John_Philip>
Date: Fri, 28 Nov 2003 19:46:59 -0500
Subject: [SDL] SDL_GetVideoInfo strangeness
Reply-To: sdl at libsdl.org

In Mac OS X with the Quartz driver, all flags returned by
SDL_GetVideoInfo() are always 0. This is obviously incorrect, can
someone familiar with SDL’s Quartz driver comment on this?

(OS X 10.3.1, SDL 1.2.6)

Message: 9

On my Mac OS X system, calling SDL_SetVideoMode(SDL_HWSURFACE |
SDL_FULLSCREEN | SDL_DOUBLEBUF) results in a surface with the following
flags:
SDL_HWSURFACE
SDL_NOFRAME
SDL_PREALLOC
SDL_DOUBLEBUF
SDL_FULLSCREEN

This SDL_Surface for the screen claims to be a hardware surface, is it
really?

No, we are emulating page-flipping behavior in this case, primarily for
the benefit of retrace-synchronized updates. The screen surface is
actually a software surface that updates to the screen in another
thread and in sync with the monitor (60hz on LCDs w/ADC or DVI). We had
to use SDL_HWSURFACE for compatibility with other platforms, otherwise
I’d leave it out to avoid the confusion.

If so, SDL_GetVideoInfo() should be returning hw_available =
true, and probably some other fields true as well.

Not necessarily. Even if we did have a true hardware screen surface,
that does not imply that the implementation can perform hardware
accelerated blits/fills. This is the case with a single-buffered
hardware surface on Mac OS X, and probably with other targets as well.On Nov 30, 2003, at 3:01 PM, sdl-request at libsdl.org wrote:

From: John Philip
Subject: Re: [SDL] SDL_GetVideoInfo strangeness
Date: Sun, 30 Nov 2003 01:56:37 -0500
To: sdl at libsdl.org
Reply-To: sdl at libsdl.org