[xinf] Future direction of Xinfinity
Daniel Cassidy
xinf at danielcassidy.me.uk
Thu Dec 21 12:23:45 CET 2006
On 12/20/06, daniel fischer <dan at f3c.com> wrote:
> hm. i like cairo for its clean C interface and its many backends. you're right
> about the "accelleration", though. agg is very beautiful- and i dont think
> performance is so lacking if you compare to flash. (i know,)
AGG *is* beautiful. And I gave it a more thorough test last night and
must admit I was forced to eat my words, because it's pretty damn
fast, too :).
Perhaps Cairo would be a good choice with a custom backend or two? I
need to do more investigation to determine whether such a thing would
be more or less hairy than just going my own way :).
> "Daniel Cassidy" <xinf at danielcassidy.me.uk> (on Wed, 20 Dec 2006 00:43:01 +0000):
> > * I really want the 2D/3D context switch to be as clean and consistent
> > as possible, both from the point of view of Xinf users, and of the guy
> > who maintains Xinfinity :). I fear that using dedicated libraries for
> > each might jeopardize this.
>
> i'd like to keep the door open for other implementations. after all, the point
> about xinf is mostly it's cross-runtimeness, and flash/js are unlikely to
> get 3d anytime soon. cairo or agg seem good options for 2d rendering on
> embedded devices. a nicely accellerated implementation is my prio too, tho.
I'm not entirely sure what you're saying here. Certainly, the ability
for Xinf to provide 2D in the absence of 3D is an absolute must. Even
in the absence of cross platform considerations, my thinking is that
embedded versions of Xinfinity are probably best kept 2D only, at
least on platforms which lack OpenGL/ES.
I do think that the 3D API can be designed to feel like a natural
extension to the 2D API and vice versa, though, and still support
this.
> i'm sure you've had a look at xinferno, the simplified rendering protocol
> i use for renderer abstraction-- i'm unsure if this can be scaled up for
> "proper" 3d-- most 3d i've been thinking of is pretty simple stuff. do you
> think it can actually be done with such a protocol, or maybe we should
> rather have a good OO scenegraph interface from haxe?
I was thinking that Xinfinity itself could do with a good scenegraph
implementation (in C), that could then be interfaced with from
haXe/Neko. That way, the player can handle rendering on its own, and
the Neko application's job will be to modify the state of the player's
scenegraph. This should significantly reduce the amount of resources
expended on communication between Neko and the player.
I really want there to be *one* scenegraph both for 2D and 3D;
something like Flash's scenegraph model, but with an extra dimension
and hopefully a little less ad-hoc. Similarity to Flash should help
when it comes to implementing a consistent API between the two, though
of course I am not interested in repeating old mistakes.
> for desktop-style apps, i think we should find
> a good solution for all neko apps. resources can be integrated nicely into
> neko modules with haxe's -resource flag.
Yes, I'm quite happy to just use -resource for desktop apps. OTOH, if
we have to build our own format for web-based applications, presumably
that format will be good enough for desktop applications too, and why
complicate things by having two formats?
> it's a different issue for xinfinity as a browser plugin: there we obviously
> need a format-like thing. it could be .n, though- with a "hardened" loader.
> i've already started to take some care about future security in xinfinity
> by not wrapping any library functions that read or write local files- so that
> all would go thru neko.io.
I think I'd like to see something a bit more advanced than just *.n
for web based stuff. One of Flash's virtues is its ability to stream
vector animations. It would be really cool if we could best that,
perhaps by extending to 3D in that arena too (I confess I have no idea
*how* :)). Your work on Strive is surely of interest here :).
> feel free to discuss anything on this list or, if you prefer, privately.
> i'm unsure if i have any good comments for everything, but you can try.
I expect you have a lot more useful comments than I have. But, as you
correctly point out below, good comments aren't always so important...
> sometimes even talking to your rubber duck helps clear your mind :)
This is very true, but unfortunately my rubber duck has a demanding
girlfriend, and doesn't have much time to talk code :).
Dan C
More information about the xinf
mailing list