[EMAIL PROTECTED] wrote:
> >> I wonder what are the advantages of using bytecode compiler and then an
> >> interpreter for Javascript when you always have to interpreter the
> >> Javascript source code from the pages.
>
> >It's both a design and a speed issue. The design issue is that it's easily
> >implemented with a bison generated parser:), the speed issue is that it's
>
> Ah, well, it's the usual tokenizing. With this all these new Internet
> manias to invent new concepts, I thought you were actually saving a byte
> code stream to disk cache.
No, it's not simply a tokenizing (this takes place before a parser is even
involved). The source text is really compiled down into the usual P-Code
representation for a virtual machine with an expression and an object
reference stack. This is nothing new, it's a standard issue when designing
compilers. A "real" compiler just generates target-architecture dependant
machine code from the P-representation.
I could save the P-Code to disk, but I doubt it would gain much.
Bison-generated parsers are horribly fast, even on Amiga-class CPUs :),
and Javascript code normally isn't excessivly large.
> >That's just a subset of the MSIE one, too.
>
> So, what features does it have besides the ones in DOM standard? Layers?
Generally, it's much more flexible in respect to what object properties can
be changed "on the fly" after the page is represented. The only "dynamic"
aspects in the Mozilla object model are document.write() and the ability
to replace Image.src (in a limited fashion).
> Talking about MSIE, is Voyager going to have a progressive HTML table
> layout engine that starts laying tables before they are fully loaded.
> Voyager has been fast in many issues, but currently it is particularly
> retarded rendering tables, even when compared with other Amiga browsers
> that also wait to load the tables definition till the end.
"www.freshmeat.net" is a good example for this. However, there are
two issues:
a) You can't really render a table before it is fully parsed, because
you simply don't know the size beforehand. TABLE WIDTH and TD WIDTH are
just advisory. Would you *could* do, however, is render the table as
far as possible, and drop all the layouting when more data is available.
I haven't implemented this yet, but it surely is possible (V does something
similiar when hitting <IMG> without size specifications)
b) I know that V is slow compared to IBrowse with deeply nested tables,
but the reason is that V does honour width advisories. You can compare
the result of a layout of www.freshmeat.net with both V and IBrowse
to see the difference. We just recently had a in-depth discussion of
this on #ibeta and during that I disabled honoring width advisories
in V (taking widths for "granted"), which reduced the total layout time
for the page to about 1/5 that of IBrowse, on the same hardware. But
the result is similarly dissatisfactional.
Olli
--
� Oliver Wagner <[EMAIL PROTECTED]>
� http://www.vapor.com
� finger [EMAIL PROTECTED]
