iOS Memory Warnings - Small Fix; How To Improve?

Hi All,

So, I have been unable to find a way to handle or detect iOS memory warnings through SDL.

The main issue is that memory warnings are usually raised by the system through the AppDelegate or ViewControllers, which are both abstracted away by SDL. My current solution has been to patch the SDL code with the following small snippet in SDLUIKitDelegate.

  • (void)applicationDidReceiveMemoryWarning:(UIApplication *)application
    {
    SDL_Event event;
    event.type = SDL_USEREVENT;
    event.user.code = 0xCAFEBABE;
    SDL_PushEvent(&event);
    }

This works well, and I just grab the event in my game’s event pump. However, I see that both event.type and event.user.code need to be changed from what I have used. I really would like to change this into something that could eventually be used a real patch, as memory warnings happen all the time in iOS (and I assume Android) and should be reacted upon.

I couldn’t really find any good event type to match, except perhaps SDL_SysWMEvent, which is why I used SDL_USEREVENT. Maybe a SDL_SYSTEMEVENT or SDL_MEMORYEVENT could be created, and then as the subtype introduce something like SDL_MEMORYWARNING, or maybe the subtype is not even needed?

Suggestions are very welcome.

Cheers,
Gorm

This really ought to be added to the API. Memory warnings are important events for embedded devices!

In Windows XP and later, there is also QueryMemoryResourceNotification which would allow a similar event to be generated for Windows.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

Finally someone who agrees with me :). I really have a hard time understanding why this hasn’t been a bigger issue yet, as it is usually quite an important issue in the development of any mobile app.On Wednesday, March 13, 2013 at 9:08 PM, Nathaniel J Fries wrote:

This really ought to be added to the API. Memory warnings are important events for embedded devices!

In Windows XP and later, there is also QueryMemoryResourceNotification which would allow a similar event to be generated for Windows.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/


SDL mailing list
SDL at lists.libsdl.org (mailto:SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

gormlai wrote:

Finally someone who agrees with me :). I really have a hard time understanding why this hasn’t been a bigger issue yet, as it is usually quite an important issue in the development of any mobile app.

  	 	This really ought to be added to the API. Memory warnings are important events for embedded devices!

In Windows XP and later, there is also QueryMemoryResourceNotification which would allow a similar event to be generated for Windows.

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/ (http://natefries.net/)

The memory warning and other callbacks have some patchs somewhere on old topics,
I think it is a good time to ressurect this discussion.> On Wednesday, March 13, 2013 at 9:08 PM, Nathaniel J Fries wrote:


Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com
Joystick Mapper for Mac - joystickmapper.com

Googling reveals also that Windows CE provides a WM_HIBERNATE message with the same intention (not sure if this is available on Windows Phone 8 or not, can’t seem to find anything about it. Since it uses the NT rather than CE Kernel, probably not)
It also reveals that there is a normal Windows message WM_COMPACTING in 16-bit Windows, which is sent when the system believes memory is low (when >12.5% of CPU time is spent compacting memory). I can’t seem to find any information about whether or not this message is still sent by modern Windows; but it might be good to handle this message just for the sake of trying.------------------------
Nate Fries

About WM_COMPACTING:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632618(v=vs.85).aspx
"Note This message is provided only for compatibility with 16-bit
Windows-based applications."

I guess it’s useless, especially since I doubt 32-bit Windows ever
compacted memory at all in the first place :stuck_out_tongue:

2013/3/14, Nathaniel J Fries :> Googling reveals also that Windows CE provides a WM_HIBERNATE message with

the same intention (not sure if this is available on Windows Phone 8 or not,
can’t seem to find anything about it. Since it uses the NT rather than CE
Kernel, probably not)
It also reveals that there is a normal Windows message WM_COMPACTING in
16-bit Windows, which is sent when the system believes memory is low (when

12.5% of CPU time is spent compacting memory). I can’t seem to find any
information about whether or not this message is still sent by modern
Windows; but it might be good to handle this message just for the sake of
trying.


Nate Fries

Sik wrote:

About WM_COMPACTING:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632618(v=vs.85).aspx
"Note This message is provided only for compatibility with 16-bit
Windows-based applications."

I guess it’s useless, especially since I doubt 32-bit Windows ever
compacted memory at all in the first place :stuck_out_tongue:

I had that feeling myself, but it doesn’t really say.------------------------
Nate Fries

Remember that "compatibility with 16-bit Windows-based applications"
means “you can port code made for 16-bit Windows without having to
rewrite it”. It’s for the same reason the unused parameter in WinMain
exists - even though in modern Windows it’s always NULL. WM_COMPACTING
is most likely never sent at all, ever.

2013/3/14, Nathaniel J Fries :>

Sik wrote:

About WM_COMPACTING:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632618(v=vs.85).aspx
"Note This message is provided only for compatibility with 16-bit
Windows-based applications."

I guess it’s useless, especially since I doubt 32-bit Windows ever
compacted memory at all in the first place :stuck_out_tongue:

I had that feeling myself, but it doesn’t really say.


Nate Fries

Since there was not suggestions for a proper way to handle this. I have cleaned up my fix and attached to this email.

Basically, I have introduced

SDL_MEMORY_WARNING as an enum in SDL_events.h, right after SDL_QUIT as I think they kind of belong in the same group together, and have been implemented in a similar way.

Then in in the AppDelegate I have added

  • (void)applicationDidReceiveMemoryWarning:(UIApplication *)application
    {
    SDL_Event event;
    event.type = SDL_MEMORY_WARNING;
    SDL_PushEvent(&event);

}

And that’s it. I hope you will accept my fix or let me know how to refactor it and I will.

I should get to the Android version in a month or two, at which time I can implement the fix for that platform as well.

Cheers,
GormOn Thursday, March 14, 2013 at 9:45 PM, Sik the hedgehog wrote:

Remember that "compatibility with 16-bit Windows-based applications"
means “you can port code made for 16-bit Windows without having to
rewrite it”. It’s for the same reason the unused parameter in WinMain
exists - even though in modern Windows it’s always NULL. WM_COMPACTING
is most likely never sent at all, ever.

2013/3/14, Nathaniel J Fries <nfries88 at yahoo.com (mailto:nfries88 at yahoo.com)>:

Sik wrote:

About WM_COMPACTING:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632618(v=vs.85).aspx
"Note This message is provided only for compatibility with 16-bit
Windows-based applications."

I guess it’s useless, especially since I doubt 32-bit Windows ever
compacted memory at all in the first place :stuck_out_tongue:

I had that feeling myself, but it doesn’t really say.


Nate Fries


SDL mailing list
SDL at lists.libsdl.org (mailto:SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_events.h
Type: application/octet-stream
Size: 24424 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130327/de487e22/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_uikitappdelegate.m
Type: application/octet-stream
Size: 9084 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130327/de487e22/attachment-0003.obj

FYI, the official set of events went in recently, with a low memory warning
included:
http://hg.libsdl.org/SDL/rev/11612d544fcdOn Wed, Mar 27, 2013 at 6:40 AM, Gorm Lai wrote:

Since there was not suggestions for a proper way to handle this. I have
cleaned up my fix and attached to this email.

Basically, I have introduced

SDL_MEMORY_WARNING as an enum in SDL_events.h, right after SDL_QUIT as I
think they kind of belong in the same group together, and have been
implemented in a similar way.

Then in in the AppDelegate I have added

  • (void)applicationDidReceiveMemoryWarning:(UIApplication *)application

{

SDL_Event event;

event.type = SDL_MEMORY_WARNING;

SDL_PushEvent(&event);

}

And that’s it. I hope you will accept my fix or let me know how to
refactor it and I will.

I should get to the Android version in a month or two, at which time I can
implement the fix for that platform as well.

Cheers,
Gorm

On Thursday, March 14, 2013 at 9:45 PM, Sik the hedgehog wrote:

Remember that "compatibility with 16-bit Windows-based applications"
means “you can port code made for 16-bit Windows without having to
rewrite it”. It’s for the same reason the unused parameter in WinMain
exists - even though in modern Windows it’s always NULL. WM_COMPACTING
is most likely never sent at all, ever.

2013/3/14, Nathaniel J Fries :

Sik wrote:

About WM_COMPACTING:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632618(v=vs.85).aspx
"Note This message is provided only for compatibility with 16-bit
Windows-based applications."

I guess it’s useless, especially since I doubt 32-bit Windows ever
compacted memory at all in the first place :stuck_out_tongue:

I had that feeling myself, but it doesn’t really say.


Nate Fries


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

FYI, the official set of events went in recently, with a low memory
warning included:
http://hg.libsdl.org/SDL/rev/11612d544fcd

So this part of the patch means that iOS SDL apps should explicitly do
SDL_PumpEvents() somewhere in their loop to work?

 9.7 -    /* we need to let the event cycle run, or the OS won't update

the OpenGL view! /
9.8 - SDL_PumpEvents();
9.9 + /
You need to pump events in order for the OS to make
changes visible.
9.10 + We don’t pump events here because we don’t want iOS
application events
9.11 + (low memory, terminate, etc.) to happen inside low level
rendering.
9.12 + */
9.13 }On Sat, May 25, 2013 at 9:01 PM, Sam Lantinga wrote:


Bye,
Gabry

SDL_PollEvent does it implicitly.

I guess the issue though is that you’re supposed to never stop
reading events. The operating system can decide your program is hung
up if you do. This is true for all platforms, just that the outcome
differs in each case. I guess that SDL_PumpEvents may be to work
around that.

2013/5/27, Gabriele Greco <gabriele.greco at darts.it>:> On Sat, May 25, 2013 at 9:01 PM, Sam Lantinga wrote:

FYI, the official set of events went in recently, with a low memory
warning included:
http://hg.libsdl.org/SDL/rev/11612d544fcd

So this part of the patch means that iOS SDL apps should explicitly do
SDL_PumpEvents() somewhere in their loop to work?

 9.7 -    /* we need to let the event cycle run, or the OS won't update

the OpenGL view! /
9.8 - SDL_PumpEvents();
9.9 + /
You need to pump events in order for the OS to make
changes visible.
9.10 + We don’t pump events here because we don’t want iOS
application events
9.11 + (low memory, terminate, etc.) to happen inside low level
rendering.
9.12 + */
9.13 }


Bye,
Gabry