> For multi-media, modern typopraphics, I think it is very poor.
> But for any sysadmin, config screens, basic lists, tables ...
I'd add 2D user interfaces to your list of what REBOL is good at, which is
the biggie for anyone developing more traditional applications. For
realtime 3D / intensive multi-media stuff, use something else.
I'd be carefull about statements that REBOL can't do x well, I have often
found that (like PERL) there is more than one way to do things and often a
change in approach / algorithm is required. As an example of this, one of
the applicaions I sell provides the facility to graphically annotate an
image (typically 6 mega-pixel) and move / resize these annotations.
The initial implementation did the following:
- apply any effect to the image (eg. grayscale)
- draw (eg. a red circle)
- square crop the viewable area of the image
- fit the image to a screen-height x screen-height display area
This approach certainly worked (apart from ending up with pixelated
drawings!), but the FPS (Frames Per Second) was down to about 0.5! At this
point I bemoaned the fact that REBOL/View was too slow and didn't let me
directly update pixels, I even looked at external libraries to handle the
drawing component but I wanted to keep the applcation 100% REBOL. I then
looked at changing my algorithm:
- square crop the viewable area of the image
- fit the image IF crop size > display area size
- apply any effect to the image (eg. grayscale)
- fit the image IF the display area size is >= crop size
- draw (eg. a red circle)
This small change increased the average FPS to about 1.5 and resulted in
clean [non-pixelated] drawings. Good, but could be better. My next change
was the biggie: instead of working with the image itself, work on the
rendered screen representation, that way, instead of having to worry about
a 6 mega-pixel image all I had to worry about was the 768x768 screen view
of it. This bought the FPS up to 40 FPS with no user-level changes.
I am now looking at similiar issues with large REBOL data structures on
small memory foot-print devices. Yes, loading a 76MB 1,000,000 row table
into a hash! solves my access problems but consumes 750Mb of memory. Now,
if I can work out a way of working with the same file in 'open/binary mode
and only use 76MB of memory ...
The point of all this is to illustrate my belief that REBOL can do most
things you want it to do, but you have to think about *how* you can do it
and what the tradeoffs of your aproach are.
Regards,
Ashley
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
