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

[REBOL] Re: Carl? Re: View in Fullscreen?? Re: Re: a demo

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 >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: > >>Hi Charles and all, >> >>Telling the truth Rebol is still slow with rendering of big faces(even >>without any difficult graphics elements!) which is really a pitty. >>I still hope RT will start things moving after finishing the SDK. Just try >>to resize the demo window ore maximize it over the whole screen and you will >>se rapid perfomance problems. I myself and sure other developers are still >>trying to convice Carl to invest some more effort to speed the View's >>preformance. There are two steps how to do it IMO: >> >>1st step) optimize OS independent routines (DRAW dialect, efect pipeline >>etc.), add possibility of direct drawing into faces without the need to >>refresh all pixels, make cool dialect for compiling performance critical >>code, expose convolve function to Rebol layer etc....that would be the first >>great step but everything will depend only on the CPU power, anyway a good >>choice for lightweight apps and small instalations without needs to have >>other dependant software and subsystems. >> >>2nd step) improve specific OS graphics handling (blitting, framebuffer even >>HW acceleration(OGL, DX)!), enhance DRAW dialect for 3D etc. ...this would >>be a absolutely killer addition to each of classic software-rendered View >>ports and bring us really great power, moreover this would push Rebol into >>nowadays real multimedia spheres or even to 3D game and entertainment and >>kill all current popular and monopolistic giants like Macromedia Flash, >>Shockwave etc.. I know, some folks here are afraid of the crossplatform >>compatibility issuses in this case but we have to take in mind that we are >>talking about graphics OS specific improvements *not* about language stuff >>itself which would remain still 100% compatible on all platforms! In other >>words code would remain the same but the graphics output would depend on the >>specific system capabilities. >> >>My personal opininon is that RT should make in future two versions of >>Rebol/View for each platform(where it is possible): one with software >>renderer only(the classic one) and the second with specific OS graphics >>optimalizations and HW support. I know that RT don't have enough resources >>for all that work so they could start at least with the most used OSes >>(probably WIN and LINUX). Moreover, there seems to be some Rebol fans on the >>list (like Bruno G. Albuquerque for BeOS) wo would like to improve specific >>ports so where is the problem Carl? ;-) >> >>Regards, >> >>Cyphre >> >>----- Original Message ----- >>From: "Charles" <[chalz--earthlink--net]> >>To: <[rebol-list--rebol--com]> >>Sent: Wednesday, December 04, 2002 8:57 PM >>Subject: [REBOL] Re: a demo >> >> >> >> >>> Gotcha Cyphre. It's quite attractive. Any idea how well it would work >>> >>as a >> >> >>>fullscreen screensaver? ;) >>> >>> >>> >>>>Hi Charles, >>>> >>>> >>>> >>>>> Thanks Gregg! Yeah, that's a pretty spiffy demo Cyphre! Though, a >>>>>question/comment: At least on my computer (running Win98SE), the very >>>>> >>>>edges of >>>> >>>> >>>>>the display retain smudges of previous spiral colors. Is this normal? >>>>> >>>>> >>>>those smudges at the edges of face are caused by some bug in View IMO >>>> >>>>regards, >>>> >>>>Cyphre >>>> >>>>-- >>>>To unsubscribe from this list, please send an email to >>>>[rebol-request--rebol--com] with "unsubscribe" in the >>>>subject, without the quotes. >>>> >>>> >>>-- >>>To unsubscribe from this list, please send an email to >>>[rebol-request--rebol--com] with "unsubscribe" in the >>>subject, without the quotes. >>> >>> >>> >>> >> >> > >-- >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