Multimedia quality (was) One disk OS + REBOL Re:(4)
[1/14] from: petr:krenzelok:trz:cz at: 23-Aug-2000 22:04
[steve--shireman--maxonusa--com] wrote:
> I did finally play around with this this morning, and came up with a
> bootible View diskette, using 498k of 880k.
<<quoted lines omitted: 10>>
> Got a rush of excitement comparing this to Multimedia players of old
> (AVision, Scala, etc.)
I still live in excitement while playing with /View - very nice product. Just a
small note - do you know Scala is more than just a tool? Have you seen any emails
from Dave Haynie describing Scala as an multimedia OS (it seems to actually have
own kernel running upon windoze one). Scala is very nice product, well thought
out, scriptable, sadly, we will probably never be able to compare to their smooth
multimedia quality presentations.
REBOL (product) doesn't seem to care about such quality of presentation. REBOL
slideshow dialect was very nice example, but try to move a few faces around the
screen - too slow, too jerky, etc. Maybe it's just question of some regularly
implemented /Media component integrating in some way with /View? I don't know. In
my opinion, while others see REBOL future in turning into some scripting agent
number one with packed in mysql etc support, I still see REBOL/Core's future in
providing just infrastructure for clever communication (improving parts as parser,
protocols, simply means of communications) and APIs. Remember - even /View is just
component upon /Core. We should be able to unplug /View than, and plug another
one, if there is some other component available.
In real - if REBOL/Core will not turn in some 5 years into something described
above and will stay just nicely implemented scripting technology, it lost my
credit, as I can see REBOL technology capable of becoming much more than it's
today ;-)
PS: Steve, where are you all the time? I can see you posting only very
sporadically here :-)
Cheers,
-pekr-
[2/14] from: g:santilli:tiscalinet:it at: 24-Aug-2000 19:37
Hello [petr--krenzelok--trz--cz]!
On 23-Ago-00, you wrote:
p> REBOL (product) doesn't seem to care about such quality of
p> presentation. REBOL slideshow dialect was very nice example,
p> but try to move a few faces around the screen - too slow, too
p> jerky, etc. Maybe it's just question of some regularly
Try to go to Scala, and tell them you want to see their product
running on xx different platforms. They'll laughing at you! :-)
REBOL/View is slow because it is too general. Its engine is really
powerful (perhaps it only lacks alpha blending). It can surely be
speeded up by using a less general approach for the common cases
(see the speed gain we got with the buffering of opaque faces).
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[3/14] from: petr:krenzelok:trz:cz at: 25-Aug-2000 0:41
[g--santilli--tiscalinet--it] wrote:
> Hello [petr--krenzelok--trz--cz]!
> On 23-Ago-00, you wrote:
<<quoted lines omitted: 4>>
> Try to go to Scala, and tell them you want to see their product
> running on xx different platforms. They'll laughing at you! :-)
Yes, I know - as Dave Haynie said - he left mainly because Scala got too
much tied to Windows. It uses DirectX IIRC. But do you remember those
glory days of Amiga and its chipset? Scala running very very smoothly on
such underpowered (by today standards) piece of hw. And what? Was it
bigger than 500 kb? And scala presentation was just script. And it had
network capabilities too.
I miss REBOL trying to participate in area of multimedia .... sad today
topic of discussion is just big boys and "e" stuff ... People forgot
having fun ;-)
> REBOL/View is slow because it is too general. Its engine is really
> powerful (perhaps it only lacks alpha blending). It can surely be
> speeded up by using a less general approach for the common cases
> (see the speed gain we got with the buffering of opaque faces).
>
It lacks slightly more :-)
- We can't change mouse pointer e.g. From days of beta2 I suggested
possibility of hiding mouse pointer, or having it replaced by two faces
- one defining area of cursor, while second one (inside) area of sensor
..
- We haven't solved yet how to display-during-downloading. (sometimes
its boring to wait till all the stuff is downloaded) ...
- It lacks proper datatypes as we know it from Amiga. RT is so much
scared about REBOL multiplatform issues one can't believe it. Move
/shell and /library into free REBOL version (/Core, /View) and let
people implement various additions. It would allow to start open-source
projects of multiplatform REBOL support libraries. But who's gonna do it
for free once we will have to pay for /Command?
- RT business model (although not publicly presented) seems to prefer
end-solution instead of technology excelence (as Carl mentioned his love
for proper modularisation etc etc. Components are not currently freely
pluggable unpluggable, can't load /View to /Command etc etc.), but
that's the world I don't understand, once you are not on your own
(venture capital), you have to take some intermediate steps to get money
back ... I can understand it, it just makes life more difficult :-)
... I just wish history would repeat and Carl would announce "back to
the roots" scenario once again, the same way as he did when he announced
REBOL2 Contra project, getting REBOL back where it should be - small,
efficient, faster - an engine (no place for not abstracted hardwired
solutions)
Cheers,
-pekr-
[4/14] from: steve:shireman:maxonusa at: 25-Aug-2000 8:57
[petr--krenzelok--trz--cz] wrote:
> Yes, I know - as Dave Haynie said - he left mainly because Scala got too
> much tied to Windows. It uses DirectX IIRC. But do you remember those
> glory days of Amiga and its chipset? Scala running very very smoothly on
> such underpowered (by today standards) piece of hw. And what? Was it
> bigger than 500 kb? And scala presentation was just script.
The script was a 'dialect' called Lingua
It is the best practical example of what a 'dialect' is that I can think
of.
> And it had
> network capabilities too.
Ahh, but not nearly as cool as Rebol's...
Hey, with serial: support, it is possible to make a platform-independent
dongle for high-value products...
Steve Shireman
(maybe Steven Wright knew lisp...)
...when I talk and sometimes you can't here me, it is because sometimes
I am in parentheses...
Steven Wright
[5/14] from: galtbarber:mailandnews at: 25-Aug-2000 15:33
Whatever Rebol code you wrote for the dongle could
easily be read by devious miscreant ne'er-do-wells.
People trying to sell expensive Rebol products may
be frustrated by Rebol's open-ness.
Some commercial systems are so large and complex
and ever changing that they dont fear customers
having the source, since if the user wasn't registered they
wouldn't get the constant flow of bugfixes and support they
need to keep the blasted monstrosity going.
Also big corporate customers tend to play by the book and
buy most of their software and are much more
reliable in this way than the typical individual user
for personal use.
Small software that just works would however be
copied endlessly without protection, is my guess.
I like free sw as much as the next guy, but it is
harder for people to find time to volunteer rather
than time that earns them income, to work on a
software project. Linux is pretty amazing,
but not all sw is going to be developed that way.
The vast majority of people bought their Linux
from somebody, like RedHat, who bundles it
with apps and so on...
If sw is all that you do and you don't have some
other way to make money, then your sw work has
got to pay or you starve. We still don't seem to have
a way to bridge the gap between commercial production
where all is paid and owned and controlled and re-inventing
the wheel and dominating the market, and freeware cooperatives
where it is friendly and less controlling but where
no one gets monetary recompense.
So, what else is new?
[6/14] from: g:santilli:tiscalinet:it at: 25-Aug-2000 20:03
Hello [petr--krenzelok--trz--cz]!
On 25-Ago-00, you wrote:
p> Yes, I know - as Dave Haynie said - he left mainly because
p> Scala got too much tied to Windows. It uses DirectX IIRC. But
p> do you remember those glory days of Amiga and its chipset?
That's platform dependance. If REBOL/View was designed with the
Amiga chipset in mind, it would probably be quite different and
would be fast on the Amigas, but not really fast on the other
systems. It was instead designed with an abstact system in mind;
probably that was too abstract, and /View is using only a little
of the power of our computers.
p> It lacks slightly more :-)
I was referring to the layering engine. Surely /View can be
enhanched a lot more than it is now, but the layering engine
already has a lot of effects...
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[7/14] from: holger::rebol::com at: 25-Aug-2000 16:42
On Fri, Aug 25, 2000 at 08:03:16PM +0200, [g--santilli--tiscalinet--it] wrote:
> That's platform dependance. If REBOL/View was designed with the
> Amiga chipset in mind, it would probably be quite different and
> would be fast on the Amigas, but not really fast on the other
> systems. It was instead designed with an abstact system in mind;
> probably that was too abstract, and /View is using only a little
> of the power of our computers.
REBOL internally keeps data in 32-bit chunky format (image!
datatype). This is efficient on pretty much every hardware
architecture, with the exception of the somewhat obsolete planar
bitmap format the Amiga chipset uses.
Planar bitmaps were great in the late 80's when it was important
to use as few bits as possible per pixel (fewer than 8 typically),
in order to achieve high resolutions with little memory. Things have
changed since then though, and today everyone is using 8, 16, 24
or 32 bits per pixel. For that chunky formats are more efficient, in
particular when manipulating individual pixels.
What makes REBOL/View relatively slow on Amigas with the native graphics
chipset is the necessary chunky-to-planar conversion. We are using
optimized Assembler code for that, but it is still a bottleneck. On
Amigas with graphics boards REBOL/View is reasonably fast (often
faster than under Unix/X running on the same hardware).
REBOL/View cannot directly use planar bitmaps for its internal
images, not only because that would require some rewrites, but
also because the up to 8 planes the Amiga hardware supports would
not be sufficient to support the various effects View provides
(blending, colorization etc.). Those effects need to operate on
32-bit images throughout, and quantize colors down to the
requirements of the display hardware only as the last step. This
makes chunky-to-planar conversion inevitable. If REBOL stored
all internal bitmaps in 8 or fewer bits then errors would add up
when processing effects and the resulting images would look "ugly".
--
Holger Kruse
[holger--rebol--com]
[8/14] from: kolla:nvg:ntnu:no at: 26-Aug-2000 3:38
On Fri, 25 Aug 2000 [holger--rebol--com] wrote:
> What makes REBOL/View relatively slow on Amigas with the native graphics
> chipset is the necessary chunky-to-planar conversion. We are using
> optimized Assembler code for that, but it is still a bottleneck. On
> Amigas with graphics boards REBOL/View is reasonably fast (often
> faster than under Unix/X running on the same hardware).
But still dog slow, even on my [P3--650MHz] linux box I find it annoyingly
slow, and I often end up clicking on buttons twice, or more. On the Amiga
(060/PPC/CVPPC) dragging subwindows inside rebol windows is like running
a macemul in HAM on a lowend A1200, faster than X doesnt really say much
as X is per def a slow memory greedy dog, no matter what hardware ;)
-- kolla
[9/14] from: allen:rebolforces at: 26-Aug-2000 15:15
----- Original Message -----
From: <[kolla--nvg--ntnu--no]>
To: <[list--rebol--com]>
Sent: Saturday, August 26, 2000 11:38 AM
Subject: [REBOL] Re: Multimedia quality (was) One disk OS + REBOL Re:(8)
> On Fri, 25 Aug 2000 [holger--rebol--com] wrote:
> > What makes REBOL/View relatively slow on Amigas with the native graphics
<<quoted lines omitted: 4>>
> But still dog slow, even on my [P3--650MHz] linux box I find it annoyingly
> slow, and I often end up clicking on buttons twice, or more.
This is interesting, I haven't seen anyone mention speed problems on Linux
before.
I must set up a linux version to test on.
I've tested View on my old faithful Celeron 333, under Win 98, Win2000, BeOS
and Amiga (under emulation).
My general observations of platform differences...
The Amiga was slow, but it sounds like it was running faster under emulation
than the older native machines. Win platforms speed is quite good, except
for iterated faces and large area scrolling. Timer events seems have a
better resolution on Win2000 than Win98.
BeOS has the fastest smoothest scrolling of all of the above.
Font rendering/display seems to be best/clearest on Windows.
Cheers,
Allen K
[10/14] from: g:santilli:tiscalinet:it at: 26-Aug-2000 14:41
Hello [holger--rebol--com]!
On 26-Ago-00, you wrote:
[why /View is slow on Amigas w/out graphic card]
Holger, I think Petr is mainly complaining about /View being not
fast enough even on modern PCs when moving faces around, as in
scrolling text etc. I think this is due to the fact that /View has
to recalculate (almost) the whole display if you're moving
transparent faces (as Text faces are). Am I correct? I seem to
recall Jim said this was going to be optimized in the future.
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[11/14] from: steve:shireman:maxonusa at: 28-Aug-2000 8:27
I think the CD32 had a special chip (HP or ?) which did chunky to
planar.
So maybe Rebol runs cool on CD32...I will have to give that a spin and
see.
Thanks for the explanation,
Steve Shireman
[holger--rebol--com] wrote:
[12/14] from: bo:rebol at: 30-Aug-2000 15:20
Steve,
I believe that was the Akiko chip, but I think it required a special
hardware call to perform the conversion. Hence, I would be surprised
if you would see a speed increase on the CD32 unless REBOL/View was
modified to make that call when running on the CD32.
Once again, Holger probably knows more about this than I do.
Take care!
-Bo
On 28-Aug-2000/8:27:14-5:00, [steve--shireman--maxonusa--com] wrote:
>I think the CD32 had a special chip (HP or ?) which did chunky to
>planar.
>So maybe Rebol runs cool on CD32...I will have to give that a spin and
>see.
>
>Thanks for the explanation,
>Steve Shireman
--
Bohdan "Bo" Lechnowsky
REBOL Adventure Guide
REBOL Technologies 707-467-8000 (http://www.rebol.com)
Download the REBOL Messaging Language
The Official Source for REBOL Books (http://www.REBOLpress.com)
[13/14] from: jkinraid:clear at: 31-Aug-2000 15:57
Hi Bo,
> I believe that was the Akiko chip, but I think it required a special
> hardware call to perform the conversion. Hence, I would be surprised
> if you would see a speed increase on the CD32 unless REBOL/View was
> modified to make that call when running on the CD32.
>
> Once again, Holger probably knows more about this than I do.
I don't think the Akiko chip can handle 32 bit per pixel chunky pixel
format, just 8 bits per chunky pixel (palette based).
Julian Kinraid
[14/14] from: dankelg8:cs:man:ac at: 5-Sep-2000 23:24
Well, a good chunky to planar converter does the conversion at copy speed,
i.e. at the speed it takes to copy a block of memory from fast to chip
memory (even faster if it uses cache prefetching..), at least on 040 +.
The limiting factor is the speed of chip mem, which is really slow :(
Cheers,
Gisle
On Mon, 28 Aug 2000 [steve--shireman--maxonusa--com] wrote:
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted