These are both good suggestions --- support for inline assembly, and
an ABI.
The platform currently supports inline assembly (inside the #pragma),
but I don't know whether this will survive the compiler port to
Java. If it doesn't, I'll add a description to the wiki of how to
find the old implementation and the documentation for it, so that an
interested party can revive it.
Are your experiences with inline assembly for swf5, or with (later
versions of) swf6 and higher? Our experience with inline assembly
was that it was useful for swf5, but that replacing it with
JavaScript improved the performance once we targeted swf6, since
there were so many registers to allocate to.
Do you want to take a stab at documenting the ABI? Even a framework
for describing it, with unanswered questions, would be helpful. If
you want to make a new page for it on the wiki, http://
wiki.openlaszlo.org/Flash_ABI would make sense as a page name, and
the platform developers can fill in material where they know it.
On Nov 30, 2005, at 8:16 AM, Asger Alstrup wrote:
[Proposal for how access Flash specific APIs]
Having access to the raw Flash API is really a must-have to create
the best applications possible, so this proposal is very much
welcomed. We are already reliying on the #pragma hack, so an
"official" way to do this would be great - especially since the
#pragma hack is fragile: if it is not followed by some dead code,
it seems that instructions might be "optimised" away. The proposal
itself looks fine as long as it is open-ended and allows access to
the full underlying API.
However, I'd like to ask for even more (or some else): The ability
to include inline flash assembly. The performance of the Flash
engine is so poor that the loss in performance due to translation
from JavaScript to the flash bytecodes is costing too much:
Especially the difficult choice of whether to put a variable in a
register or use the top stack element as "register" costs a great
deal of performance. For maximum performance, you really need to
decide this yourself, so flash assembly is the way to go.
So some mechanism to include assembly would very much be welcomed,
whether it is based on flasm, or in the worst case, maybe even just
hex-codes. (Neoswiff supports inline assembly, and flasm allows
ActionScript to contain assembly as well.)
Another thing is documenting the ABI so that interoperability with
other Flash technologies becomes possible. There are lots of
different Flash technologies these days: Flex, Neoswiff, Xamlon,
Mtasc, haXe, flasm, and so on. And for each of these, there are
lots of libraries: actionstep, flex components, and what not. If it
was technically possible to mix & match different technologies,
that would really open the door for making nice stuff quickly. This
shouldn't be technically hard, since the Flash canvas & runtime is
the common building block, but it does require the ABI to be
documented to allow bridging conventions: The ability to access
variables and functions, and interact with the "GUI" loop.
Laszlo is great for dynamic user interfaces that are quickly put
together, and to some extend XML based stuff. However, it is not so
great for user interfaces with lots and lots of dynamic visual
elements or performance critical data processing - the overhead is
simply bringing things to a crawl, making it unworkable for really
complex stuff.
The other main problem I see with Laszlo is programming in the
large: Without static type checking, it is difficult to manage a
large project with many different programmers. Simple refactoring
is difficult, because you get no help from the compiler to make
sure all instances are caught.
Regards,
Asger Ottar Alstrup
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
