[epiar-devel] To thread or not to thread (the video code)

[Chris Walton]

I don't have time, but I've got alot to say about the subject. I'll write
out a more detailed email when I get back later.

-- Chris

On Sun, Dec 27, 2009 at 9:27 AM, Christopher Thielen <chris at epiar.net>wrote:

> In response to #1, it looks like Matt already filed the bug (
> http://epiar.net/trac/ticket/36). I've made it a blocking bug for 0.2.0.
>
> On Dec 26, 2009, at 11:47 PM, Christopher Thielen wrote:
>
> > I talked to ebos in #epiar last night and he runs Epiar on Debian in a VM
> that runs very slowly, about 8 fps. To fix this, he implemented some
> threading to separate out the drawing code, which is the slowest code. By
> doing this, he says the fps jumps to 10-20 fps.
> >
> > A couple of questions and a debate starter:
> >
> > 1) He said the game actually runs half speed at half fps. This should
> send off red flags right away. Who wrote the current timer we have? We must
> have a separation of game loop counts and real time. All position updates,
> etc. must be based on real time, not on the number of game loops, e.g. so a
> sprite covers just as many pixels per second regardless of whether the
> update loop runs twice a second or 10000 times a second. This must be fixed
> ASAP. It should be done in the Timer code, and we should also interpolate
> the coordinate positions (ask Arke or see Dan Olfson's SDL fixed rate pig
> demo (google that)).
> >
> > 2) Anybody know why, if the video drawing code is in its own thread but
> still drawing just as slowly, we would see more frames per second? This
> makes little sense to me. Somebody please answer it.
> >
> > 3) Here's the debate I want started: should we make a video thread or
> not?
> >
> > ebos says yes. It runs faster on his VM, making his life better, and
> helping Epiar.
> >
> > I say no. It's unnecessary to support his VM, or any computer that can't
> run Epiar at at least 16 fps (the minimum accepted imo for playability).
> It's also dangerous to thread unnecessarily. Threading causes timing bugs
> and memory violation bugs and even if you're careful and use a good design
> pattern, it can bite you in the ass. It should be avoided in areas where
> it's not necessary. Since implementing a proper interpolated timer
> (described in my #1) would solve his playability issues and any computer's
> playability issues, it needs to be implemented anyway, so why not just do
> the safe thing that we have to do and not do the dangerous thing that only
> helps one person? Additionally, it requires a lot of changes to the code:
> locking and unlocking variables, etc. I vote a very strong no and might
> reject it from the final tree if I'm not convinced.
> >
> > Thoughts?
> >
> > - Chris
> > _______________________________________________
> > epiar-devel mailing list
> > epiar-devel at epiar.net
> > http://epiar.net/mailman/listinfo/epiar-devel
>
>
> _______________________________________________
> epiar-devel mailing list
> epiar-devel at epiar.net
> http://epiar.net/mailman/listinfo/epiar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://epiar.net/pipermail/epiar-devel/attachments/20091227/748cd5b5/attachment.html