Carl? Re: View in Fullscreen?? Re: Re: a demo

Heya, Cyphre! :-) I would not put it better myself. What you describe sounds like a dream to reboller's heart :-) Imagine Carl is busy and although he installed separate PC for monitoring ml, you should drag his attention by adding his name to subject, that may work :-) Just one comment to what you wrote - I think that as for Windows, there would be just one version needed - do you think there is any W9x, W2K/XP user, not actually using DirectX? -pekr- Cyphre wrote:

Hello, Saw your note. I just want to clarify a few things for the group... (BTW, just a reminder, that this email list is not the best path to REBOL eyes. Use feedback system if you want to be sure that we see your ideas.) (And, sorry for the length of this, but you asked.) First, REBOL/View is not slow. It moves pixels to the screen in fast C code, pretty much the way all other software and games do. Off-screen memory is transferred to the screen at the full speed of your hardware. The problem, however, comes from two areas: 1) Heavy compositing. Many developers use View without understanding the consequences of their actions (and, that's very much our fault for not providing better low-level docs on how this all works.) They may be causing hundreds of faces (areas of the screen) to be recomputed each time they simply move the mouse. This actually tells you how fast REBOL really is. If you were to watch the underlying actions that are taking place (e.g. the recomputation of gradient fills, alpha channel blending, z layering, etc.) you'd be pretty surprised how much is being done in real-time. 2) Automatic double buffering. Objects in REBOL are not drawn directly to the screen. They are drawn as much as possible off-screen, where all the effects are applied, then blitted to the screen as needed. This can be problematic, because if you want to change just one pixel on the screen, you may be forced to write out an entire face to the screen (potentially the entire screen). That's how double buffering works. We optimize this in REBOL with some smart refresh of areas, but in the end, you still write more than what you need if you are changing single pixels. It also needs to be pointed out that the double buffering method is what makes REBOL so system independent as well. All graphics are computed at 32 bits, then converted to screen RGB when blitted. That makes REBOL work identically between systems like Windows, Linux, Unix, Silicon Graphics, etc. Unfortunately, it also means that REBOL is moving a lot of data to the screen. (Consider how X windows works in it's internal client/server model, and you will better understand the problem with regard to pure machine independence). How can we improve on it? We think a few steps are necessary: 1) Better docs. We need to tell you precisely what's going on, so you can take advantage of the compositing engine. 2) Better intermediate layering. We will be the first to admit that we've implemented various demos and tools w/o giving much thought to the refresh computation required. There are many areas where we can go back and speed up the graphics by a lot with wiser use of REBOL code. 3) At that point, we'd be ready to tackle what you have as #1, and we've talked with you about that before. Most of the improvements will actually come from documentation, with perhaps a few internal coding optimizations (we will see about that). 4) Your #2 option is interesting, but loaded with problems. For instance, many games and graphics programs run into problems with the range and variation of not only graphics cards, but versions of the OS graphics API itself. For example, an app that runs fine on XP may bomb on Win98 due to older version of the API. That's not an easy problem to solve. Consider the fact that we now have about 6 versions of Windows that we test REBOL on, multiply that by 4 or 5 software revisions. We'd need to test REBOL on 24 to 30 systems. And, we've not even mentioned Linux, Mac, SGI, Solaris, BeOS, and required systems. Perhaps one way to solve this problem would be to provide an external interface method for graphics. We've not thought totally about how this would work, but think "Amiga" here. We've already been considering allowing plug-ins for REBOL image datatype saving and loading (e.g. you want to use REBOL to convert a TIFF and output a JPG). It might be possible to provide a similar technique for graphics API functions. The advantage of this proposal is that the external graphics code would be open, allowing developers to improve it, port it, and most importantly, test it with a variation of systems and configurations. This would eliminate most of our headache of testing, while allowing you to get what you need. Of course the downside would be that REBOL would not work everywhere or machine independently. We consider that a huge downside actually. Consider it. Think it over, and let us know. BTW, I've got a separate question for you, but I'll be posting it separately here for discussion. And, yes, the SDK is top on our list. Second to that is a list of bug fixes that we want to make very soon to all versions of REBOL, Third, View docs. Then... (your imagination). -Carl REBOL Chief At 03:39 PM 12/5/02 +0100, you wrote:

>Heya, Cyphre! :-) >I would not put it better myself. What you describe sounds like a dream to >To unsubscribe from this list, please send an email to >[rebol-request--rebol--com] with "unsubscribe" in the subject, without the quotes.

Carl, thank you very much for sharing your ideas with us, appreciated it! As for optimisation, I noticed some View patch by Gabriele or Romano, posted on AltME - it simply filters repetitive events once event system is overloaded or so I understand. Maybe it is not all that correct explanation, but hopefully Gabriele or Romano will step-in and send enhancement request to your Feedback and then let us know here feedback's reply .... As for some other enhancements which could be probably add to native code, I remember old Express discussion with Holger .... ---------- Probably. The plan is to allow all outline rendering (lines, circles, boxes etc.) to use the fill pen instead of the normal outline pens. That in combination with fill patterns gives you the ability to use arbitrary images as stencils, even for lines. ---------- Cyphre: For removing timeouts without hiding a face ? The solution is probably something like "face/changes: 'timeout show face" in the next version. We are already using face/changes in some other places to limit the work show has to do, and to avoid flickering. Seems like a natural addition. ------- But what did I liked most last week during AltMe session? DVM - dialect virtual machine :-) We already have 'draw, right? It would be coold to see some other specialised dialect based virtual machines (ports) for things like math or pixel manipulation. That way per pixel manipulation could be speed up ... ... or maybe poke/pick /dup-only refinement, allowing us to poke/pick block of different values at certain position, escaping the need for iterations ... Well, anyway, thanks once again for your reply and as for the idea of plug-ins - I think if you go that route, you should not limit it to image loaders/savers, but allow some pluggable components even in some other areas, exposing some internal rebol API to allow developers to work with some of rebol datatypes from external library (component code). Awaiting your "separate question" you are about to post :-) -pekr-

Thanks Carl! Docs first please! If RT can provide some examples of what works best, and what *not* to do, in our code, that would be great. Some notes about "when you do this ... it causes this ..." would be super too. Some things might require code examples, but many things could just be human level discussions. E.g. "If you're writing a side-scroller game, don't build a huge layout that contains the entire world, instead do ... and to scroll the screen do ...". -- Gregg

Hi Romano again ;-) ----- Original Message ----- From: "Romano Paolo Tenca" <[rotenca--telvia--it]> To: <[rebol-list--rebol--com]> Sent: Saturday, December 07, 2002 1:40 AM Subject: [REBOL] Re: Carl? Re: View in Fullscreen?? Re: Re: a demo

> Hi Cyphre, > > -"to-image face" with one blur effect.............less than0:00:00.01 at > Ciao > Romano

>> img: load-thru/binary http://www.rebol.cz/~cyphre/bay.jpg ;original

>> test: make face [image: img size: img/size effect: [rotate 180 blur]]

>> img2: to-image test ;result is new image with all effects applied

>> test/image ;still the original image here

>> view layout [img3: image img effect [rotate 180 blur]] ;you will see

>> img3/image ;still the original image data here

>> img = img3/image

>> img = test/image

>> img = img2

>>

Hi Romano, ----- Original Message ----- From: "Romano Paolo Tenca" <[rotenca--telvia--it]> To: <[rebol-list--rebol--com]> Sent: Saturday, December 07, 2002 1:05 AM Subject: [REBOL] Re: Carl? Re: View in Fullscreen?? Re: Re: a demo

> That 'show makes more 300 draw line and a blur. It is not show itself, is

> to be slow (but i do not know if blur can be more fast). Removing blur on

> system, show become twice fast. >

Hi Cyphre, On Tuesday, December 10, 2002, 9:39:55 AM, you wrote: C> == make image! [192x144 #{ C> C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8 C> C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C... Are you sure that this is bay.jpg rotated and blurred? It looks like a gray rectangle to me. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

Hi Gabrielle, the gray pixels are the face's edges I forgot to set to none, just a small detail ;-) but the functionality is still the same...

>> img: load-thru/binary http://www.rebol.cz/~cyphre/bay.jpg

>> test: make face [image: img edge: none size: img/size effect: [rotate 180

>> img2: to-image test ;result is new image with all effects applied

Hi Cyphre, i can't explain exactly why, but you can see with your eyes that if you use an already displayed face, the rendering of effects starts only after show: img: load-thru/binary http://www.rebol.cz/~cyphre/bay.jpg test1: make face [image: img size: img/size] view layout [ test2: image img button "try" [ k1: to-image test1 test1/effect: [rotate 180 blur] k2: to-image test1 show test1 k3: to-image test1 v1: to-image test2 test2/effect: [rotate 180 blur] v2: to-image test2 show test2 v3: to-image test2 view layout [ text "not displayed" image "start" k1 image "before show" k2 image "after show" k3 return text "displayed" image "start" v1 image "before show" v2 image "after show" v3 return ] ] ] So the difference in behaviour here is between displayed/not-displayed image. If i remember well your time calculation was about an already displayed face, so the rendering is done by show not by to-image. --- Ciao Romano