[SDL] SDL 1.3 roadmap...

[Sami Näätänen]

On Thursday 11 October 2007, Scott Harper wrote:
> On Oct 11, 2007, at 4:18 AM, Sami Näätänen wrote:
> > On Wednesday 10 October 2007, Ross Smith wrote:
> >> One thing I'd like to know about SDL 1.3: Is it going to finally
> >> remove the restriction that SDL functions can only be called from
> >> the main thread? SDL's strong orientation to an old-fashioned,
> >> single-threaded, event-driven architecture is the reason I'm
> >> currently investigating alternative libraries. It's just getting
> >> more and more painful trying to reconcile SDL with a heavily
> >> multithreaded application.
> >>
> >> I could live with restricting all SDL calls to a single thread if
> >> I had to, if only it didn't have to be the main thread. Is there
> >> any prospect of some relief on the horizon?
> >
> > Well you can make another thread as the main thread. No one is
> > forcing you to consider the thread that can access SDL as the main
> > thread.
> >
> > I think that due to the modern HW SDL should provide more support
> > for multithreadded applications. This should be through API calls,
> > so that single threaded aplications don't suffer from the support.
> >
> > I think there are people like you who are much better at answering
> > what
> > kind of API that should be.
>
> Forgive my ignorance, but in all my study of games/graphics
> programming (which, while extant is not by any stretch of the
> imagination "comprehensive" or "in-depth") I've not run across a
> situation wherein the qualification that all drawing be performed in
> a single thread would be terribly problematic to design around, if in
> fact any conflict arose at all in the first place.
>
> More simply, I've written multi-threaded programs, and never had to
> deal with even WANTING to draw from another thread.  I've always
> designed my games to gather information for drawing each element
> (which information may be changed in separate threads), and drawing
> it; or elements that require a redraw request it and then the main
> thread gets the request and redraws however is best/

This is the easiest way of doing things and as such it will be easier 
than trying to spread the drawing around. 

> Can you provide an example scenario wherein the ability to draw from
> multiple threads becomes necessary?  I'm still learning, so maybe I
> haven't yet run across it.

Ther are some rare cases where that could be faster, but I can't think 
any that really would reguire or largely benefit by drawing from 
multiple threads if it is using only single GFX-card.