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

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

 [1/9] from: petr:krenzelok:trz:cz at: 5-Dec-2002 15:39

Librarian comment

Recent versions of REBOL/View include an AGG (Anti-grain graphics) library; much of this discussion has been implemented by that.

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:

 [2/9] from: carl::s::rebol::com at: 5-Dec-2002 9:25

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
<<quoted lines omitted: 106>>
>To unsubscribe from this list, please send an email to >[rebol-request--rebol--com] with "unsubscribe" in the subject, without the quotes.
-Carl Carl Sassenrath Founder & Chairman REBOL Technologies

 [3/9] from: petr:krenzelok:trz:cz at: 5-Dec-2002 19:33

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-

 [4/9] from: greggirwin:mindspring at: 5-Dec-2002 12:14

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

 [5/9] from: cyphre:seznam:cz at: 10-Dec-2002 9:39

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
<<quoted lines omitted: 14>>
> Ciao > Romano
Yes, have look at this:
>> img: load-thru/binary ;original
image == make image! [192x144 #{ B34533B44634B44634B54735B74735B84836B84836B84836BA4837BA4837 BC4837BC4837BC4837BC4837BC4837BA4837B94834B...
>> test: make face [image: img size: img/size effect: [rotate 180 blur]]
;test-face used for to-image operation
>> img2: to-image test ;result is new image with all effects applied
== make image! [192x144 #{ C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8 C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C8C...
>> test/image ;still the original image here
== make image! [192x144 #{ B34533B44634B44634B54735B74735B84836B84836B84836BA4837BA4837 BC4837BC4837BC4837BC4837BC4837BA4837B94834B...
>> view layout [img3: image img effect [rotate 180 blur]] ;you will see
rotated image with blur
>> img3/image ;still the original image data here
== make image! [192x144 #{ B34533B44634B44634B54735B74735B84836B84836B84836BA4837BA4837 BC4837BC4837BC4837BC4837BC4837BA4837B94834B...
>> img = img3/image
== true
>> img = test/image
== true
>> img = img2
== false
>> it looks like: - TO-IMAGE renders the face with all applied effects and return the result but without blitting to the screen and without modifying the face's image while -SHOW renders the face with all aplied effects too and blits the result to the screen without modifying the face's image What do you think? Regards, Cyphre

 [6/9] from: cyphre:seznam:cz at: 10-Dec-2002 9:36

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. >
I think TO-IMAGE is calculating the blur effect with all DRAW commands as well while SHOW makes the calculations too + blits the image data on the when you subtract those two values: -to-image face" with one blur effect.............less than0:00:00.01 at 300x300 -"show face"............~0:00:00.07 at 300x300 you got 0.01 for effect processing and 0.06 for blitting during the SHOW in this case? for more please, see my next post in this thread... regards, Cyphre

 [7/9] from: g:santilli:tiscalinet:it at: 10-Dec-2002 12:53

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:

 [8/9] from: cyphre:seznam:cz at: 10-Dec-2002 15:17

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
== make image! [192x144 #{ B34533B44634B44634B54735B74735B84836B84836B84836BA4837BA4837 BC4837BC4837BC4837BC4837BC4837BA4837B94834B...
>> test: make face [image: img edge: none size: img/size effect: [rotate 180
blur]] ;now it is *without* the edges
>> img2: to-image test ;result is new image with all effects applied
== make image! [192x144 #{ 64AEC673BDD55FA6C14388A3387C9932729022607E286180285C7A0C3C58 113E591842592B53663E62744368766B96A7ADE6FFB... regards, Cyphre

 [9/9] from: rotenca:telvia:it at: 10-Dec-2002 18:49

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 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

  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted