Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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
> formats? If not, is it fast enough to decode it if you wrote the decoder
> 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
> AVI? Once again, you should be able to add in movie support or codec
> by writing it in REBOL itself assuming it truely is a complete platform
> 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
> us to implement "whatever" in the language itself, not being dependant
> 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
> 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