[REBOL] Re: facts we will have to face ...
From: pwoodward:cncdsl at: 23-Oct-2001 13:37
I think some of these are actually valid concerns...
> Can REBOL do audio? Does it support MP3 native? How about more obsure
audio
> formats? If not, is it fast enough to decode it if you wrote the decoder
in
> REBOL itself?
REBOL can "do audio" - it is able to play .wav files. Native MP3 support
isn't in there as far as I know. While that would be nice, I'm not sure
it's necessary at this juncture. OTOH maybe being able to launch apps for
playback, much like launching a web browser would be a good interim
solution. But, I seriously doubt that a MP3 decoder would be terribly fast
written in REBOL. Perhaps one of the cross-platform audio libraries would
be handy for this... A standardized REBOL library wrapper around a widely
available mp3 (or other) audio library might meet the need.
> What about movies? Can it play sorenson quicktimes? Does it have support
for
> AVI? Once again, you should be able to add in movie support or codec
support
> by writing it in REBOL itself assuming it truely is a complete platform
like
> they say it is.
Very similar question to the first one. Again, a solution might be to allow
for the "launch" of a player outside of REBOL. Trying to embed video
playback tools into REBOL would likely swell the size of the application
well beyond it's relatively tiny footprint. AVI and Quicktime support are
handled by 2 downloads which are over 5MB each on the Windows platform -
since QT .movs aren't handled well by MediaPlayer, and MediaPlayer formats
don't play well on QT...
Perhaps a basic MPG format would be ideal. MPG playback codecs are freely
available for a wide variety of platforms, and seem to manage fairly well on
even mediocre hardware (my old '020 A1200 managed em fine).
> I mean - if Rebol should be regarded being platform, it would have to
enable
> us to implement "whatever" in the language itself, not being dependant
upon
> language kernels directly - I mean - sound, video, math, etc., the area
> where rebol speed will be badly noticed.
Very good point. A possible solution might be something similar to the
mechanism employed in a number of JVMs. They cache native code that has
been interpreted. Or perhaps a nice (for pay) way to do it would be REBOL
accelerator plugins - which feature optimization of certain segments of the
REBOL interpreter... Seamlessly replacing how certain code is interpreted
and executed to accelerate certain types of math operations, or whatever...
> I think that maybe RT should prepare some FAQ answers regarding this
issue,
> because if Rebol will become popular, newcomers will ask about possibility
> to compile and speed things up ....
While on the one hand, it's a safe bet that computational power will
increase, and so will users effective bandwidth (witness more peer-to-peer
solutions) I'm unwilling to be _greedy_ about resources. JVMs are typically
a hog when it comes to that. Once up and running, they can be pretty speedy
for most general user tasks. Hard-core math tends to suffer under Java -
but sometimes (esp. in scientific apps) the portability is worth it.
Accelerating the JVM has been a long, slow process of optimization.
Essentially the most advanced ones incorporate a profiler into the code
caching algorithm. Some unroll loops. All of them use more RAM.
Food for thought.
- Porter
