Well, I now have a much higher respect for pthreads and linux threads :)

The communication system I'm using for the majority of that player-proggy
delivers a message within 45 milliseconds on my computer...

Using a socketpair takes ~17000 milliseconds just to poll(..) to see if
there's data.  Is there a better way?
I -need- to shave this ~17000 milliseconds off!

Incidentally, quicktimes take ~40000 milliseconds/frame to decode and
mpegs take ~200000+ milliseconds/frame....  15fps only allows a maximum of
~66000 milliseconds per cycle.  (I can understand with the quicktimes -
I'm using motion-jpeg compression and jpeg-style compression's never been
known to be efficient)

incidentally: (seperate threads)
        sound playing: ~750us/frame
        video rendering: ~7000us/frame unscaled; ~12000us/frame scaled

Basically, the movie decoders are too slow.  Time to build new ones.
>From the license, Loki's plaympeg should do the trick *grin*.

BTW: Joysticks crash under GII/GGI.  Any reason?  (I -am- running a USB
joystick through the HID drivers, so it's entirely possible it's a kernel
bug - I'll look some more)

I haven't removed the code from the ggiplay (should I change the name?)

Oh, and I quelled a -nasty- bug in the videorenderer where it would
continuously re-render graphics regardless of the queue...  so folks who
found it too slow might find it works now.  But if anyone can direct me to
a half-decent MPEG/2 library, tell me, eh? :)

G'day, eh? :)
        - Teunis

Reply via email to