SDL_FULLSCREEN memory leakage

SDL Development
1

SDL_BUGS…

A couple of dreadful bugs I found while trying to make
a simple fullscreen
window under windows ME (but Im sure it all happens in
all other windows…)
and while running various SDL demos I found on the
web.

SDL_FULLSCREEN
Huge memory leakage/eats up a big chunk of memory when
it loses focus
while in fullscreen mode…
minimizing and returning to fullscreen a mere 7 times
will deplete all
system resources and crash my pc…
The memory seems to return if you exit the app before
that happens,
but this is still bad!

Notes:
Ive tried everything! there is no way around it
besides switching to DirectX,
or not using the SDL_FULLSCREEN flag within windows…
which is pretty lame.
You cant really release a professional game that will
run on windows without this…
(well not a fullscreen one anyway…)
And Im sure you know SDL_WM_ToggleFullscreen doesnt
work in windows… (why not?!)

Icons
(just a little bug)
Iconifying the window with SDL_WM_IconifyWindow() will
not display the loaded icon
when in fullscreen mode.
Notes:
a workaround that seems to work for me is to change to
windowed mode
before calling this function…

I really hope this will get fixed in the new version
of SDL… !
I dont know why SDL is moving on to dreamcast and Ps2
when it doesnt even work
in windows yet!!!__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

2

window under windows ME (but Im sure it all happens in
all other windows…)

Are you certain that what you’re seeing is an SDL problem or an SDL DEMO
problem? I don’t get the memory leaks you’re talking about in either of my
SDL based apps.

of SDL… !
I dont know why SDL is moving on to dreamcast and Ps2
when it doesnt even work
in windows yet!!!

Stop whining, grab the source, and fix it - or don’t use it. And don’t
assume that just because you see it that everyone else does. You don’t
even post the version of SDL that you’re using. Coming off with an
accusatory 'tude like you’ve just done will not win you any friends. HAve
you ever considered a better approach of offering to help or just
inquiring instead of your pathetic, whiny comments like the above?

–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me

3

I agree with you 100%, Neil, but geez, don’t you think you were just a wee
bit hard on him? You might have phrased it a tiny bit more gently. :wink:

JeffOn Monday 14 October 2002 05:34 pm, you wrote:

Stop whining, grab the source, and fix it - or don’t use it. And don’t
assume that just because you see it that everyone else does. You don’t
even post the version of SDL that you’re using. Coming off with an
accusatory 'tude like you’ve just done will not win you any friends. HAve
you ever considered a better approach of offering to help or just
inquiring instead of your pathetic, whiny comments like the above?

4

I think you were right on point Neil. He obviously didn’t feel the need to
try and help with the perceived problem but had no problem complaining about
it.

Steve

  > Stop whining, grab the source, and fix it - or don't use it. And

don’t> > assume that just because you see it that everyone else does. You don’t

even post the version of SDL that you’re using. Coming off with an
accusatory 'tude like you’ve just done will not win you any friends.
HAve
you ever considered a better approach of offering to help or just
inquiring instead of your pathetic, whiny comments like the above?

I agree with you 100%, Neil, but geez, don’t you think you were just a wee

bit hard on him? You might have phrased it a tiny bit more gently. :wink:

Jeff

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

5

In case no one scared you off yet:

Huge memory leakage/eats up a big chunk of memory
when it loses focus while in fullscreen mode…

When your app loses focus in fullscreen mode, all of its hardware
surfaces are trashed. When the app regains focus, you probably
reload all your surfaces. Did you forget to free the old surfaces by
any chance?–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com

6

When your app loses focus in fullscreen mode, all of its hardware
surfaces are trashed. When the app regains focus, you probably
reload all your surfaces. Did you forget to free the old surfaces by
any chance?

     BTW, is reloading the surfaces the only way to do it? I thought

about leaving a copy on memory after initialization so whenever I needed
them I would just convert them, but this seems to be a waste of memory.
Also, I still don’t test to check if my app lost focus (so I get trashed
hardware surfaces whenI do it ^_-), is using SDL_GetAppState and checking
the FLAG returned to see if SDL_APPACTIVE is set the way to see if my app
has lost focus and if it got it back at a later stage?

     Paulo
7

When your app loses focus in fullscreen mode, all of its hardware
surfaces are trashed. […]

     BTW, is reloading the surfaces the only way to do it? I

thought

about leaving a copy on memory after initialization so whenever I
needed
them I would just convert them, but this seems to be a waste of
memory.

I still have to build this into my own engine, but for me it is
probably easiest to free the surfaces with SDL_FreeSurface() and
load or create them again with SDL_LoadBMP() or
SDL_CreateRGBSurface(), since that fits in with my resource manager.
However, the surface is still there and only its data is gone, so
you can also just copy over the pixel data to surface->pixels again.
This is described somewhere in the SDL docs.

Also, I still don’t test to check if my app lost focus (so I get
trashed
hardware surfaces whenI do it ^_-), is using SDL_GetAppState and
checking
the FLAG returned to see if SDL_APPACTIVE is set the way to see if
my app
has lost focus and if it got it back at a later stage?

I think you should catch the SDL_ACTIVEEVENT event for this.–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com

8

I still have to build this into my own engine, but for me it is
probably easiest to free the surfaces with SDL_FreeSurface() and
load or create them again with SDL_LoadBMP() or
SDL_CreateRGBSurface(), since that fits in with my resource manager.
However, the surface is still there and only its data is gone, so
you can also just copy over the pixel data to surface->pixels again.
This is described somewhere in the SDL docs.

     So anyway if I don't want to reload them from disk, I am most

likely going to keep a copy of the surfaces on memory :/. Anyway, has
someone had experience on programming vertical/side scroller 2D games? Is
the performance gained, if any, using ony hardware surfaces (sprites,
tiles, etc) worth the trouble to avoid such problems (or worth using
hardware surfaces for that, anyway)? Because I tested using only software
surfaces (changed the flags on initialization, duh :P) and I had no video
problem on changing from my full screen app to Windows and coming back.

     Also a bit on the subject, when I changed, I paused the game and

changed back to Windows, and the music (using SDL_Mixer) was playing just
fine, but when I returned to my app (fullscreen) the sound was choppy for
some seconds. Later the sound was playing normal, but it just seemed weird
and if someone knows a way to avoid it, I would appreciate.

the FLAG returned to see if SDL_APPACTIVE is set the way to see if
my app
has lost focus and if it got it back at a later stage?

I think you should catch the SDL_ACTIVEEVENT event for this.

     Ok, back to my handle event function :).

     Paulo
9 
     So anyway if I don't want to reload them from disk, I am most

likely going to keep a copy of the surfaces on memory :/. Anyway, has
someone had experience on programming vertical/side scroller 2D games? Is
the performance gained, if any, using ony hardware surfaces (sprites,
tiles, etc) worth the trouble to avoid such problems (or worth using
hardware surfaces for that, anyway)? Because I tested using only software
surfaces (changed the flags on initialization, duh :P) and I had no video
problem on changing from my full screen app to Windows and coming back.

Hardware surfaces are definitely worth the effort on Windows (no support on
linux). The gain in speed is good, but the fact that ‘tearing’ is avoided
is the best thing I find, especially when working with a game that requires
smooth scrolling.

Checking when you lose your surfaces and then reloading them can be a pain,
though :(.

     Also a bit on the subject, when I changed, I paused the game and

changed back to Windows, and the music (using SDL_Mixer) was playing just
fine, but when I returned to my app (fullscreen) the sound was choppy for
some seconds. Later the sound was playing normal, but it just seemed weird
and if someone knows a way to avoid it, I would appreciate.

the FLAG returned to see if SDL_APPACTIVE is set the way to see if
my app
has lost focus and if it got it back at a later stage?

I think you should catch the SDL_ACTIVEEVENT event for this.

     Ok, back to my handle event function :).

Yep, that’s what I do to. I’m still testing, since I’ve had one person
reporting that switching between windowed mode and back again occasionally
crashes the app on his machine, so I’m not sure I’ve got everything right.

10

dreadful bug I found while trying to make a simple
fullscreen
window under windows ME (but Im sure it all happens in
all other windows…)
and while running various SDL demos I found on the
web.

SDL_FULLSCREEN
Huge memory leakage/eats up a big chunk of memory when
SDL programs lose focus while in fullscreen mode…
minimizing and returning to fullscreen a mere 7 times
will deplete all system resources and crash my (new)
pc… The memory seems to return if you exit the app
before that happens, but this is still bad!

Ive tried everything! there is no way around it
besides switching to DirectX, or not using the
SDL_FULLSCREEN flag within windows…

And Im sure you know SDL_WM_ToggleFullscreen doesnt
work in windows… (why not?!)

I really hope this will get fixed in the new version
of SDL… !
I dont know why SDL is moving on to dreamcast and Ps2
when it doesnt even work in windows yet!__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

11

dreadful bug I found while trying to make a simple
fullscreen
window under windows ME (but Im sure it all happens in
all other windows…)
and while running various SDL demos I found on the
web.

Never seen it on Win9x or win2k, but I could have missed it, of course…

SDL_FULLSCREEN
Huge memory leakage/eats up a big chunk of memory when
SDL programs lose focus while in fullscreen mode…
minimizing and returning to fullscreen a mere 7 times
will deplete all system resources and crash my (new)
pc… The memory seems to return if you exit the app
before that happens, but this is still bad!

What kind of display surface are you using? (SDL_HWSURFACE, SDL_DOUBLEBUF
etc.)

Ive tried everything! there is no way around it
besides switching to DirectX, or not using the
SDL_FULLSCREEN flag within windows…

And Im sure you know SDL_WM_ToggleFullscreen doesnt
work in windows… (why not?!)

Because that would require that the display surface struct is replaced
every time you switch. AFAIK, the problem with that is that
SDL_WM_ToggleFullscreen() was never defined as a call that may need to
close and reopen the display, and thus, implementing it on Win32 would
break many applications.

I really hope this will get fixed in the new version
of SDL… !

I’m sure it will (the memory leak issue, that is), if someone can figure
out what’s actually going on.

Anyone seen this leak before?

I dont know why SDL is moving on to dreamcast and Ps2
when it doesnt even work in windows yet!

Probably because the people working on those ports are not the same
people that are working on the Win32 support. How is stopping development
on all other fronts going to help any particular target? heh

On the contrary, in my experience, working on multiple platforms at once
results in the common code getting much more solid than if you work on
only one platform. The different environments and tools have a tendency
of revealing nasty bugs before they have a chance to cause real trouble.

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

.- Coming soon from VaporWare Inc…------------------------.
| The Return of Audiality! Real, working software. Really! |
| Real time and off-line synthesis, scripting, MIDI, LGPL…|
-----------------------------------> (Public Release RSN) -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture |----------------------------> http://www.linuxdj.com/maia -’
— http://olofson.net — http://www.reologica.se —On Wednesday 16 October 2002 04:40, Jason Robertson wrote:

12

There is support for hardware surfaces with DGA (which I think is a bad
idea – root access: blah, blah, blah), and with fbcon (which I rather
like)…On Tue, 2002-10-15 at 16:01, Rob Sadedin wrote:

Hardware surfaces are definitely worth the effort on Windows (no support on
linux). The gain in speed is good, but the fact that ‘tearing’ is avoided
is the best thing I find, especially when working with a game that requires
smooth scrolling.

13

There is support for hardware surfaces with DGA (which I think is a bad
idea – root access: blah, blah, blah), and with fbcon (which I rather
like)…

Excuse me for being ignorant, but what is DGA and fbcon?

Paulo

14

Yep, that’s how I’m doing it, and it seems to be working …> ----- Original Message -----

From: pvwr@sympatico.ca (Paulo Vinicius Wolski Radtke)
To:
Sent: Tuesday, October 15, 2002 9:26 PM
Subject: Re: [SDL] Re: SDL_FULLSCREEN memory leakage

When your app loses focus in fullscreen mode, all of its hardware
surfaces are trashed. When the app regains focus, you probably
reload all your surfaces. Did you forget to free the old surfaces by
any chance?

     BTW, is reloading the surfaces the only way to do it? I thought

about leaving a copy on memory after initialization so whenever I needed
them I would just convert them, but this seems to be a waste of memory.
Also, I still don’t test to check if my app lost focus (so I get trashed
hardware surfaces whenI do it ^_-), is using SDL_GetAppState and checking
the FLAG returned to see if SDL_APPACTIVE is set the way to see if my app
has lost focus and if it got it back at a later stage?

     Paulo

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

15

SDL has several backends on each platform. For instance, under Win32 it
supports both DirectX and DIB interfaces. In Linux, X is just one of
many interfaces that it supports. DGA is an extention to X that allows
processes with ‘root’ permission to directly access the video card
(somehow still through the X protocol, but I don’t know too many details
on this)… fbcon (or “Frame Buffer Console”) is a kernel option that
emulates text mode on a graphics framebuffer. fbcon is optional on x86
and standard on non-x86 Linux. If your kernel supports fbcon, you
probably see a graphical Tux at the begining of your system booting
Linux. It can display graphics on the emulated text mode when told to
do so. The nice thing about fbcon with respect to SDL is it requires
neither X nor root access. There are also other backends availible
under Linux: svgalib allows you to control the video card from a
terminal, but requires root access. GGI is availible although it’s
vastly less popular than it used to be. AAlib allows you to run SDL in
"ascii-art" mode. (I’m sure there are a few more… just can’t think of
them right now.)

Hope that helps,

-LorenOn Wed, 2002-10-16 at 11:50, pvwr at sympatico.ca wrote:

There is support for hardware surfaces with DGA (which I think is a bad
idea – root access: blah, blah, blah), and with fbcon (which I rather
like)…

Excuse me for being ignorant, but what is DGA and fbcon?