[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
www.rebol.com
