SDL Threaded Input

In a standard SDL Event loop, you poll events, then do some logic processing.

There was a patch a few months ago that added “timestamp” to the
SDL_Event structure. Has anyone looked into using it to get more
precise input events? It looks like it is set when the event is
created (when SDL_PumpEvents is called).

Would the best approach be multithreading, splitting the event
handling from the video handling? From the wiki, it looks like
SDL_PumpEvents has to be called from the same thread that initialized
the graphics.

Nathan Coulson, Dreaming of keyboard input with more precision then the fps.------
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com

Mixing events in different threads may be a bad idea. If you’re not
getting good results (slow processing), what you may want is to distribute
some sort of event handling in a thread, which would mean poll in the main
thread, and once you get an event that will take some processing power,
process it in a new thread.
For an engine I’m working on (it’s c++ so it may not be 100% relevant), I
have 4 worker threads that I can enqueue custom events to do some
processing in the background.
I do this through subclassing, but you could easily achieve the same using
callbacks.

-AlexOn Mon, May 21, 2012 at 2:55 AM, Nathan Coulson wrote:

In a standard SDL Event loop, you poll events, then do some logic
processing.

There was a patch a few months ago that added “timestamp” to the
SDL_Event structure. Has anyone looked into using it to get more
precise input events? It looks like it is set when the event is
created (when SDL_PumpEvents is called).

Would the best approach be multithreading, splitting the event
handling from the video handling? From the wiki, it looks like
SDL_PumpEvents has to be called from the same thread that initialized
the graphics.

Nathan Coulson, Dreaming of keyboard input with more precision then the
fps.

Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com


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

processing’s fine, there’s no reason I actually need this. I just
saw a world where I thought it was possible (just use the timestamp
variable), until I realized that the timestamp is generated when
SDL_PollEvents was called. (and if I did manage to get it working, I
was not sure if it would have any effect at all)

It does sound like threads would be the way to make this work, and it
looks like SDL_GL_SwapBuffers does not have to be in the same thread
as the input handling. I’ll have to try that out when I get farther
along.

I wonder what it means, when I do not have any good reasons to code my
dream. Other then to see if it can be done…On Mon, May 21, 2012 at 6:23 AM, Alex Barry <alex.barry at gmail.com> wrote:

Mixing events in different threads may be a bad idea. ?If you’re not getting
good results (slow processing), what you may want is to distribute some sort
of event handling in a thread, which would mean poll in the main thread, and
once you get an event that will take some processing power, process it in a
new thread.
For an engine I’m working on (it’s c++ so it may not be 100% relevant), I
have 4 worker threads that I can enqueue custom events to do some processing
in the background.
I do this through subclassing, but you could easily achieve the same using
callbacks.

-Alex

On Mon, May 21, 2012 at 2:55 AM, Nathan Coulson <@Nathan_Coulson> wrote:

In a standard SDL Event loop, you poll events, then do some logic
processing.

There was a patch a few months ago that added “timestamp” to the
SDL_Event structure. ?Has anyone looked into using it to get more
precise input events? ?It looks like it is set when the event is
created (when SDL_PumpEvents is called).

Would the best approach be multithreading, splitting the event
handling from the video handling? ?From the wiki, it looks like
SDL_PumpEvents has to be called from the same thread that initialized
the graphics.

Nathan Coulson, Dreaming of keyboard input with more precision then the
fps.

Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com


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


Nathan Coulson (conathan)

Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com

Are you trying to squeeze more performance out of SDL or do you just want
to have more logic FPS than drawing FPS (that’s what your dream sounds like
to me)?

Jonny D

I think OpenGL 3.x and above is threadsafe, but otherwise, you’ll have to
keep any GL style call in the same thread.
-AlexOn Wed, May 23, 2012 at 8:37 AM, Jonathan Dearborn wrote:

Are you trying to squeeze more performance out of SDL or do you just want
to have more logic FPS than drawing FPS (that’s what your dream sounds like
to me)?

Jonny D


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