SDL_ToggleFullScreen, kill it or fix it!

While working on the multiwindowing code for SDL I have come to know
SDL_ToggleFullScreen better than I ever wanted to. It is only
implemented by the X11 driver and adds a fair amount of complexity to
that driver. While taking a shower I was thinking about what parts of
the multi-window code I hadn’t properly tested and toggle full screen
was at the head of the list. My first reaction was that since it adds
complexity and is not supported by any other driver it should just be
yanked out by its roots. Remove the documentation, remove the
declarations, and just forget about it.

Then I though a bit more and realized that with multiwindow support
SDL_ToggleFullScreen is not needed, an application can switch to full
screen by just creating a new full screen window setting things up to
talk to that window and hiding the old window. The switch back is just
the opposite show the hidden window, hide to visible window, and you
have done it.

As I continued washing (my water bill says I take long showers…) I
also realized that by adding some (alot?) of complexity to the level
above the drivers it would be possible to implement SDL_ToggleFullScreen
in a driver independent way. The complexity comes from keeping child
windows in sync on both of the top level windows. All in all, this would
be an ugly hack that doesn’t seem worth the effort.

So, what do you think? Mac and Windows users and all those working with
frame buffers have been living without SDL_ToggleFullScreen forever, no
portable application uses it, and soon(?) you will be able to get the
same effect without using it. Should we just junk it?

	Bob Pendleton-- 

±-------------------------------------+

Hello !

For me: Kill it. Just replace
it with a Dummy function.

CU

Count me in too. SDL_ToggleFullScreen screws up portability and goes
against the spirit of SDL (since it works as intended on only one
backend). It should be obsoleted. How many times has someone asked for
a new feature to SDL and got a “it is too platform-specific” reply,
even though SDL_ToggleFullScreen – a very platform-specific
function – is right there in the public API?On 3/14/06, Torsten Giebl wrote:

For me: Kill it. Just replace
it with a Dummy function.

  • SR

So, what do you think? Mac and Windows users and all those working with
frame buffers have been living without SDL_ToggleFullScreen forever, no
portable application uses it, and soon(?) you will be able to get the
same effect without using it. Should we just junk it?

            Bob Pendleton

I use SDL for it’s portability and simplicity.
This function seems to fit neither.

My preference would be to have it scrapped.

remove it. One can always destroy and recreate its window. if he/she
absolutely requires this feature.On 3/14/06, Brian Barrett <brian.ripoff at gmail.com> wrote:

So, what do you think? Mac and Windows users and all those working with
frame buffers have been living without SDL_ToggleFullScreen forever, no
portable application uses it, and soon(?) you will be able to get the
same effect without using it. Should we just junk it?

            Bob Pendleton

I use SDL for it’s portability and simplicity.
This function seems to fit neither.

My preference would be to have it scrapped.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

In which case why not simply define it to do just that?

Which

  • moves the problem out of the driver code as desired,
  • retains compatibility, which is desirable,and
  • provides the feature on ALL systems which is
    an extra bonus :)On Wed, 2006-03-15 at 10:44 +0100, Olivier Delannoy wrote:

remove it. One can always destroy and recreate its window. if he/she
absolutely requires this feature.


John Skaller
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net

because that would change the SDL_Surface that is the video screen.

Since we don’t return it’s new value it is not obvious to the caller
that all existing references to the surface that was returned from
SDL_SetVideoMode() are invalidated.

And that would break compatability.On 3/15/06, skaller wrote:

On Wed, 2006-03-15 at 10:44 +0100, Olivier Delannoy wrote:

remove it. One can always destroy and recreate its window. if he/she
absolutely requires this feature.

In which case why not simply define it to do just that?

Which

  • moves the problem out of the driver code as desired,
  • retains compatibility, which is desirable,and
  • provides the feature on ALL systems which is
    an extra bonus :slight_smile:


John Skaller
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

It’s not possible in the library cause it require the recreation of
all user surface. but some of them such as the one storing in memory
image do not need changes. If I remember well.On 3/15/06, skaller wrote:

On Wed, 2006-03-15 at 10:44 +0100, Olivier Delannoy wrote:

remove it. One can always destroy and recreate its window. if he/she
absolutely requires this feature.

In which case why not simply define it to do just that?

Which

  • moves the problem out of the driver code as desired,
  • retains compatibility, which is desirable,and
  • provides the feature on ALL systems which is
    an extra bonus :slight_smile:


John Skaller
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

It’s not possible in the library cause it require the recreation of
all user surface. but some of them such as the one storing in memory
image do not need changes. If I remember well.

Ah, I see. OK, thanks. Also to brian ripoff.On Wed, 2006-03-15 at 12:33 +0100, Olivier Delannoy wrote:

On 3/15/06, skaller <@john_skaller> wrote:

On Wed, 2006-03-15 at 10:44 +0100, Olivier Delannoy wrote:

remove it. One can always destroy and recreate its window. if he/she
absolutely requires this feature.

In which case why not simply define it to do just that?


John Skaller
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net

In which case why not simply define it to do just that?

Because the semantics of ToggleFullScreen() require it to keep the same
surface pointer, and the same “pixels” field in that surface (not to
mention state/textures/etc on a GL context).

I say remove it, but leave a stub function that always fails, flag it as
deprecated with a GCC attribute and change the docs to say “don’t
call this, only here for binary compatibility.”

–ryan.

a nice ld link warning in the .c code would be sweet … then just mark the
header with attribute ((deprecated))
-mikeOn Wednesday 15 March 2006 23:11, Ryan C. Gordon wrote:

In which case why not simply define it to do just that?

Because the semantics of ToggleFullScreen() require it to keep the same
surface pointer, and the same “pixels” field in that surface (not to
mention state/textures/etc on a GL context).

I say remove it, but leave a stub function that always fails, flag it as
deprecated with a GCC attribute and change the docs to say “don’t
call this, only here for binary compatibility.”

Because the semantics of ToggleFullScreen() require it to keep the same
surface pointer, and the same “pixels” field in that surface (not to
mention state/textures/etc on a GL context).

I say remove it, but leave a stub function that always fails, flag it as
deprecated with a GCC attribute and change the docs to say “don’t
call this, only here for binary compatibility.”

Actually, since this change is proposed for the 1.3 API, I think we can
safely remove it. SDL 1.3 won’t have binary compatibility with 1.2,
though it will probably be mostly source compatible.

I’m sorta addicted to the easy fullscreen toggle in Loki games though. :slight_smile:
As far as I know that’s a trick nobody else has ever duplicated en masse.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

a nice ld link warning in the .c code would be sweet … then just mark the
header with attribute ((deprecated))

Yeah, that’s a neat trick. :slight_smile:

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

While I do agree that binary compatibility is more important, I don’t
see why this should be removed - so long as it reliably and detectably
fails on architectures where it is not supported.

As long as the docs are clear that it may not work, and are clear on how
to detect this failure, why make everyone do this less efficiently if
it’s possible to do it better (especially considering it is already
implemented)? Certainly there may be other platforms in the future
where this will be possible, no?

IMHO, having a standard way to detect if it will work or not (without
having to attempt it, so you can know if you should offer the support or
not if you are not going to implement totally reinitializing the video)
would be a better upgrade than just ripping it out. Perhaps the best
solution is to just add a boolean SDL_CanToggleFullscreen() function (or
similar)?On Wed, Mar 15, 2006 at 08:38:27PM -0800, Sam Lantinga wrote:

I’m sorta addicted to the easy fullscreen toggle in Loki games though. :slight_smile:
As far as I know that’s a trick nobody else has ever duplicated en masse.


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060316/b9773255/attachment.pgp

While I do agree that binary compatibility is more important…

I meant to say “cross-compatibility”, not “binary compatibility”.
Sorry, was a late night.On Thu, Mar 16, 2006 at 03:01:14AM -0500, Stea Greene wrote:


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060316/9939a42c/attachment.pgp

I’m sorta addicted to the easy fullscreen toggle in Loki games though. :slight_smile:
As far as I know that’s a trick nobody else has ever duplicated en masse.

While I do agree that binary compatibility is more important, I don’t
see why this should be removed - so long as it reliably and detectably
fails on architectures where it is not supported.

The main reason to remove it is that were are adding new features that
allow all versions of SDL running on windowing systems to accomplish
the same effect without needing device level support. Another reason is
the complexity of the underlying code. It adds a lot of complexity to
the X11 driver.

All in all, it seems better to make the code less complex and get rid of
the incompatibilities than to keep this feature around.

As long as the docs are clear that it may not work, and are clear on how
to detect this failure, why make everyone do this less efficiently if
it’s possible to do it better (especially considering it is already
implemented)? Certainly there may be other platforms in the future
where this will be possible, no?

Seems like a long shot bet to me. My bet is they will implement some
kind of windowing system, which we can use.

IMHO, having a standard way to detect if it will work or not (without
having to attempt it, so you can know if you should offer the support or
not if you are not going to implement totally reinitializing the video)
would be a better upgrade than just ripping it out. Perhaps the best
solution is to just add a boolean SDL_CanToggleFullscreen() function (or
similar)?

	Bob PendletonOn Thu, 2006-03-16 at 03:01 -0500, Stea Greene wrote:

On Wed, Mar 15, 2006 at 08:38:27PM -0800, Sam Lantinga wrote:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+

Because the semantics of ToggleFullScreen() require it to keep the same
surface pointer, and the same “pixels” field in that surface (not to
mention state/textures/etc on a GL context).

I say remove it, but leave a stub function that always fails, flag it as
deprecated with a GCC attribute and change the docs to say “don’t
call this, only here for binary compatibility.”

Actually, since this change is proposed for the 1.3 API, I think we can
safely remove it. SDL 1.3 won’t have binary compatibility with 1.2,
though it will probably be mostly source compatible.

I didn’t realize it was already in the plan. I’ll go ahead and rip it
out of my code. Just leave a stub that always fails.

I’m sorta addicted to the easy fullscreen toggle in Loki games though. :slight_smile:
As far as I know that’s a trick nobody else has ever duplicated en masse.

Yeah, I like it too. I could say that that features is proof of the
conceptual superiority of the X11 model over all other windowing
systems. But, if I said that someone would shove it down my throat and I
might even start a flame war. So, I didn’t just say that. :slight_smile:

	Bob PendletonOn Wed, 2006-03-15 at 20:38 -0800, Sam Lantinga wrote:

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


±-------------------------------------+

Sam Lantinga wrote:

Because the semantics of ToggleFullScreen() require it to keep the same
surface pointer, and the same “pixels” field in that surface (not to
mention state/textures/etc on a GL context).

I say remove it, but leave a stub function that always fails, flag it as
deprecated with a GCC attribute and change the docs to say “don’t
call this, only here for binary compatibility.”

Actually, since this change is proposed for the 1.3 API, I think we can
safely remove it. SDL 1.3 won’t have binary compatibility with 1.2,
though it will probably be mostly source compatible.

I’m sorta addicted to the easy fullscreen toggle in Loki games though. :slight_smile:
As far as I know that’s a trick nobody else has ever duplicated en masse.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

I would miss that too. That hacked SDL lib I used with Neverwinter Nights
was sweet.

Sounds smart to me. I will miss it though. Not for full production
level apps (they would always implement it themselves anyway), but for
those simple one-afternoon apps that you just throw together intending
only X11 support. It was very nice to have this so easy.On Thu, Mar 16, 2006 at 01:27:13PM -0600, Bob Pendleton wrote:

All in all, it seems better to make the code less complex and get rid of
the incompatibilities than to keep this feature around.


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060316/56a3772c/attachment.pgp