The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

SDL has had ports to the iPhone and homebrew NintendoDS for quite some time now, and older versions of SDL are also used in webOS and homebrew PSP development (SDL 1.3 is supposedly available as part of webOS "PDK" now too). Last year it gained an Android port as well. However, it hasn't met the demands of these lower-power devices.

The typical SDL application polls for events and then draws, with no idea of the demands of these low-power systems in maintaining battery life. In fact, SDL doesn't provide any sort of "should redraw" notification for applications intended to run on these devices. Applications running in such a manner will kill the battery rather quickly compared to apps that correctly render only when needed (the programmer will know: render when the screen needs to be updated, or after a "should redraw" event happens). This would be the equivalent of a Win32 application using WM_PAINT, an X11 application using the "Expose" event, an OS X application overriding NSView's drawRect member function, an iOS application overriding UIView's drawRect member function, or an Android application overriding android.view.View's onDraw member function/android.opengl.GLSurfaceView.Renderer's onDrawFrame member function.

Another issue is low memory warnings. I know for a fact that both Android (android.app.Activity's onLowMemory() function) and iOS (UIApplicationDelegate's applicationDidReceiveMemoryWarning function) provide these warnings, SDL should generate an event for them.


Just thoughts as I was researching Android and iOS application development. Good luck.

I agree with what you're saying, but I don't think it completely fits
the philosophy of SDL. SDL has always been a bare-bones system, and
it should be up to the programmer to figure out the power needs of a
particular device.
On the flip side, however, I can see that this would work well with
the currently implemented event system.
From there, we have two options - build SDL with a new event for
redrawing, or just use the built-in user event interface.

Honestly, this sound like it would be good for either a forked version
of SDL, or some sort of user add-on library, rather than residing in
SDL's core.

Those are just my thoughts - maybe some people will desire this to be
built in, and i'm sure ryan or another dev will accept a patch if
there is enough community desire for a power-friendly paint event.
-Oz

On Tue, Jul 19, 2011 at 7:20 PM, Nathaniel J Fries wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Implementation of either of these will require a massive rewrite of the Android port, because SDL hijacks the main thread (and frankly, I'm not really sure the best route to go with SDL for supporting).
It probably does the same on iOS (they actually have similar basic application models), meaning it will require a rewrite as well.
It would be impossible to implement with an add-on library, since in both cases it depends on a part of the system that is completely obscured by SDL. It would require a fork or a rewrite.

Obviously SDL's API allows for this, although it may not be hooked up at
the moment for iOS, etc. This is fixable.

I had a patch for 1.2 floating around to make SDL_WaitEvent() do a true
wait instead of polling, so that embedded devices could go to an idle
state when the user wasn't touching anything. I'd like to make something
like that a formal part of 1.3 if possible. It could be done with the
existing SDL_WaitEvent(), we'd just have to make sure everything that we
care about can be marshaled into a single select() (or whatever) call.


This is a good idea.

--ryan.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org