World: r3wp

terribly slow... but nice source of data... that's good thing with 
SVG.. it's easily parseable

A friend of mine works for ESRI (the source of the data), this was 
a test project for them.  Very slow, but it culd be very fast.  They 
need to intigrate teh DOM with the Data (sectioning off stuff).

To convert this world viewer to REBOL should be very easy.  It would 
be a good test of VID3, and of DRAW.  And it would be instant cool 
(and actually useful).

Do you think we could add kind of PCode to Draw?

IIRC, some guys wanted some "save points"(?), so that once you render 
some bunch of vectors, you would save the rendering state, so that 
next time you could reuse it without no need to re-render.

but don't take me serious, I could misunderstood the issue.

You have to ask cyphre

REBOL would make good use of Pcode, since it would still be parsing 
at the same level.  Yeah, saving the "State" of a vector render would 
in theory be very fast then.

There are a lot of not so well thought out things about SVG (or I'm 
missing it in some way).  For example, you "animate" at the object 
level.

In my mind it should be:

- Make list of objects.
- Group some of them.
- Animate by reference.

But SVG seems to be simply:

- Make an object, embed animation.
- Next object.

Reichart - do you know - http://www.caligari.com/? Maybe good enough 
to "record" stuff around your house? Hmm, but maybe way too much 
complicated for what you need ...

If you want Pcode for SVG, use one of the binary XML encodings like 
EBML. If you want Pcode for REBOL, that's what Rebin is to be.

Yup, I knew Roman (the founded) when he introduced his stuff at SIGGRAPH, 
an when he first showed Calagari on the Amiga.  His stuff has come 
a LONG way.  Very impressive (very cool guy too).
I need only a 2D scripting system though.


BrianH, I did not know about EBML, but I don't see the advantage 
of EBML, or Rebin for that matter.  PCode (in my simple mind) servers 
several purposes:

- Portability to multiple systems.
- Faster execution
- Smaller size

Pretty much in that order.


Back when I did video games, I designed a language called MIDAS (which, 
while it looks like I made the name fit the acronym, I did not….Machine 
Independent Demonstration and Animation System)


It was designed to do the opening credits, scores, dialogs, win sequences, 
and it produced simple (very very simple pcode) out to the C64, IBM, 
Amiga, etc.  All you had to do was convert the art, and we had a 
tool to do that too.


Each command would become 1 byte (since there were less than 256 
commands.  So it produced something that looked like assembly.


With both EBML and Rebin, there would be (I assume) still parsing, 
unless you are writing everything yourself (in other words, a player).

= founded, serves.

You have to parse Pcode too - it's just easier to do so (I have).

Parsing is not as big a deal as people make it out to be - it is 
just decoding a stream of binary structured in a particular way.

We agree, it is easy....but that may have sidestepped my question...


Exactly why have Pcode for EBML or Rebin?  If there were a standard 
for the back end for EBML, for example, there was a Pcode reader 
(player) written in C, removing the complex parser, then this would 
make sense to me.  Perhaps I'm missing something?

What you are missing is what Pcode really is. Pcode was originally 
Rebin for Pascal, but has turned into a generic term for encodings 
that serve this function for a wide variety of languages or semantic 
models. Rebin _is_ a Pcode.

Hmmm...I am still not following here.  I know the history of Pcode. 
 But you used "Rebin" above to imply a Pcode for REBOL.
I'm still not seeing why this would be worth it.

I want to see this (undertand it), I'm just not getting it.

It does not (seem to me) match the three reasons to do it
 
- Portability to multiple systems.
- Faster execution
- Smaller size

Both XML and REBOL already work on multiple systems, I don't perceive 
much of a speed increase, and now-a-days, Zip works great.  WE did 
not have that as a standard 20 years ago.

Here's a breakdown for any encoding (Pcode, XML, REBOL, whatever):

Portability:

You need to build or acquire a decoder or encoder, and third-party 
code would need to as well. Advantage: XML


Faster execution: The main way you get that is to make the model 
of your data format match your data model. If the match is close 
enough you can translate the data to your internal model in insignificant 
time, like EBML to XML, Rebin to REBOL, or CPU instructions. If your 
internal semantic model is simple enough you can quickly do a direct 
interpretation of the data, like older Pcode interpreters or the 
original Java byte code, or the micro-operations inside modern CPUs.


In the case of REBOL, we have it easy because REBOL is primarily 
a data model. All we have to do is encode that data in an efficient 
binary format and then decode that format to the memory model. That's 
Rebin, the proposed Pcode of REBOL.


In the case of XML, it is slightly more difficult because there are 
competing binary encodings, and none of those will be supported in 
a web browser until it wins the format war. EBML is like a Zip for 
the XML data model, rather than its syntax (similar compression algorithm 
too) - much faster than unzipping XML and parsing it. The main problem 
is that only Matroska decoders support it right now - no web browsers. 
Similar constraints exist for the other binary encodings of XML.


In the case of SVG, we are much less lucky. SVG has its own data 
model on top of the XML data model. Once you decode the XML from 
whatever format it was encoded in, you end up with data of the XML 
model - then you have to interpret that data to get a dataset in 
the SVG model, much like the relation between REBOL and the Draw 
dialect. There may be some advantage to coming up with a Pcode for 
SVG.


The main thing that you need to keep in mind is that your Postscript 
experience is throwing you off: The semantic models of modern graphic 
formats are declarative, not programmatic - this was the main change 
between Postscript and PDF. A Pcode for a modern graphic model would 
not be executed like code, it would be loaded as data.

R, I doubt that Adobe has any committment to SVG now.

Graham - but if SVG is W3C standard, everybody will use it, no matter 
what, no?

Shall we list for Pekr the W3C standards that are widely ignored 
or misimplemented by everyone?

Not all W3C standards though.

Is there any better body for submissions? If not W3C, web would not 
exist, as MS vs Netscape were each going their own route.

SVG is widely implemented by those who actually pay attention to 
standards. That does not include the companies behind the majority 
of the content on the web: Microsoft and Adobe.

By "behind" I mean "who set the standards for", sorry.

What does have Adobe to do with it? They don't have any web browser. 
As for MS, in EU Firefox is reaching 50%

Who cares for IE. If it would be for me, I would drop its support 
altogether. And yes, I am anti MS fanatic :-)

What does have Adobe to do with it?

 The majority of vector content on the web is either in Flash or PDF 
 format.

Flash and vectors? Blah .... Flash is slow junk, just used by everybody 
... Good for adverts, not apps ...

PDF is cool.

Adobe was supporting SVG before they bought Macromedia - now they 
have dropped SVG for Flash.

But you are right, Flash sucks for apps.

Please note that Adobe has announced that it will discontinue support 
for Adobe SVG Viewer on January 1, 2009.

AFAIK, Adobe has discontinued downloads of the SVG Viewer already 
:(

i JUST DOWNLOADED THE PLUG-IN

That's how I found the above quote

Clearly "AFAIK" isn't far enough :)

Interesting conversation on SVG ... perhaps it would be better to 
continue in the SVG Renderer group (or just rename it to SVG?) no?

IE needs the Adobe plugin to view SVG.  I believe but have not seen 
it working that FF has/were building their own viewer built in.

I don't agree, that "Flash is slow junk". It was very well designed 
for creating interactive animations. And it supports things, which 
SVG is missing... as for example possibility to cache vector drawing 
as a bitmap. If something is slow, in most cases it's not Macromedia's 
fault.

maybe it's not that slow, but still, Flash is junk

BrainH, I won't belabour the point, I'm simply still unclear how 
once can make REBOL really much faster by making byte-code from it. 
 But, perhaps someone will, and make a demo, and prove it to me in 
the future… I agree that Zip XML is not a solution, but unless the 
Pcode system for XML is built into the browser, I don't see an advantage 
there either yet.

I'll be the first to use both though, when they exist.

Ashley, yes, will move future SVG convo to group…

Rebolek: tell me why?

Reichart, Rebin won't make REBOL run faster internally, but it would 
improve the storage and transmittal of REBOL data, so things like 
/Services would be faster. Internally REBOL is already fast.

I know most people here are still treating SaaS as a red headed step 
child…but guys, it IS what is happening…  : )

Check this out:

http://code.google.com/apis/chart/#url_format


They got to it before Richard and I could complete ours, and given 
there license (don't worry about it if you use it less than 250K 
times a day!), we are probably just going to support it directly.


How about writing a REBOL interface that lets you test it first, 
then out puts Google compatible REST?


Even without Google Charts, it is a stand alone useful program, but 
WITH Google, it might get noticed by the public.


One should be able to whip this together quickly, and it would be 
a useful simple report component everyone could use.

that was released quite a while ago wasn't it?

I didn't think it could do time series ...so I didn't persue it.

It gets better, all the time...Google has a habit of that...

can't see that they do it yet