Ashley I agree with most of what you say, but because we do not have acces to rebol from the outside, we cannot compliment it, if we need it.
In the example you give, in my workflow I still have to render the 6k image, cause it will go to film print (and then projected on screen at a movie near you). working in thumbnail isn't an option at my level. but I can't solve the problem, in this case, unless I can use rebol's data directly. For example, text/font drawing in rebol is a farce (I can't change that). Face does not handle anti-aliasing for any of its graphics (I can't change that). things like that REALLY are important when you want to create vertical APPLICATIONS. That's the problematic word -APPLICATION-. rebol is THE BEST for quick and dirty but has many shortcommings for full-blown apps (for which it was not destined, initially). I remember a post from Carl S. where he admits (in a quick comment, long ago) that there are more people using rebol as a GPL (General Purpose Language) than he tought would have and that he should change some things in the roadmap to adapt for this reality... but left no details... If we COULD implement such things ourselves (by having binary access to rebol's data via plugin modules OUTSIDE of rebol), then those issues CAN be fixed by anyone who really needs the solution. Adding external hooks, for example, giving us a face object's raw binary bitmap memory space, when rebol is finished drawing. This would let us add gfx to that face's bitmap in REAL TIME with external plugins (many of which ARE multiplatform) and then returning when the bitmap is ready, would allow me to use rebol as a production-quality compositing software, no slow interpreted data transformations need to be done as the image supplied as raw pixel info would be used direcly by the external binary code and then quickly refreshed in the window. same thing for converting raw window events into better keyboard support, IF I need it. Currently I can only do some pre-canned effects, put laim-quality typography and add very limited transformations. If you want a list, just ask Cyphre he's stopped ranting, having done it for soooo long, without much effect (maybe view 1.3 altme world is making his requests move along more?). I want to incorporate image-magik into rebol ASAP (during the course of this year for sure), but I can't use it for the actual in-rebol view window in real-time. I can only see it being a real-time thing, if image-magik's processing is done in separate memory space (in a window a canned .dll would open by itself) using a simple dialected string version of a processing tree, which it executes line-by-line with absolutely no inteligence. It could also be done as a stand-alone process ,using a tcp-port for receiving commands, but then we haven't solved anything really... anyhow, back to work... -MAx --- "You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun." > -----Original Message----- > From: Ashley Trüter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 7:09 PM > To: [EMAIL PROTECTED] > Subject: [REBOL] Re: starting to be really late!? > > > > > 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. > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
