World: r3wp

PNG can't scale, no? And I can be PNG file smaller than vectors transferred? 
The slowness of whole stuff is another thing.  Dunno if we can support 
SVG out-of-the-box. We are using AGG, while the rest of the world 
is using Cairo.

And since Adobe has Mocaromedias knowhow, why thay should use SVG 
scripting... but with such a corporations one never knows

it's a shame I don't know the link... I would post you the SVG source... 
how large it can be

and PNG does not scale, but do I scale web page?

Don't forget that SVG is XML so it can be very large if you draw 
something more complex

OK, but do you think that it is a bad thing to have vector gfx available? 
That way, VID3 UI will be scallable. Carl also said, that there is 
some space for improvement. What Cyphre thinks is, that maybe we 
could get compound rasteriser workind, which could speed things up 
a bit (Flash uses it)

Yes, DRAW is MUCH better than SVG though.  Hence I was thinkning 
about just doing a dialect mostly in DRAW with an SVG emiter.
There is SVGZ (zipped SVG), but Pcode would be better.

PNG is a container...so it can contain Raster, Vector, well, actually 
it can contain anything (sort of like Amiga IFF format).

I'm not agains vector graphics... I just don't like SVG

The point of SVG is that it is the lowest common denom...

That will ALWAYS suck, but at least you know things will render.

And I'm FOR vector, but also don't like SVG.  But if it is a standard, 
I will support.  It will mean I can send you a graphic, and you can 
display it with just a browser.

Why there are no SVG maps but everybody is using PNG layers?

What do you mean Maps?

just an example

Do you mean map as in Earth?

Check this out: http://croczilla.com/svg/samples/svgtetris/svgtetris.svg

yes

so what? should I send you some Flash site link?

This is not a compitition...............just showing a cute example. 
 You guys sure do jump to the negative quickly...

It's slow, but here is the US in SVG http://apps.arcwebservices.com/svgviewer/map.html

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.