[xinf] Fw: Re: Xinfinity scenegraph

[Daniel Cassidy]

On 12/24/06, daniel fischer <dan at f3c.com> wrote:
> "Daniel Cassidy" <xinf at danielcassidy.me.uk> (on Sat, 23 Dec 2006 01:25:13 +0000):
>   > What *is* dramatically different is that I'd like to see this stuff
>   > implemented in the player itself, in C, for speed, and xinfony's high
>   > level API more or less directly wrapping to a fairly-high level
>   > representation in the player.
>   >
>   > However, for some reason some of the rationale for the seperation of
>   > xinfony/xinferno/xinfinity is only just starting to defuzz in my
>   > brain, and I suspect that you will feel I've just uttered the most
>   > utterly daft thing you've ever heard :).
>
> i've heard quite a few dumber things, especially from politicians :)
> seriously though, iteration1 of xinf didnt have the erno/ony separation,
> and i feel *much* more comfortable with it. the xinfony layer is really
> very thin, and erno will allow for quite some neat tricks in the future.
> it is so thin that i don't see much point in "accellerating" it with C,
> the basic support for an object model is in the erno interface (with its
> startObject etc). i.e., i'd really like to keep renderer implementations
> on the erno level, so ony has to know as little as possible about runtimes.

Yes, I completely appreciate the value of this seperation. But, it's
worth pointing out that my concern is not so much to accelerate the
xinfony layer itself (which *is* very thin), but the *combination* of
xinfony and xinferno. It is here that my gut tells me that there are
some big gains to be had.

I'm going to have a big think about how I can do all or most of what I
want, preferably without soiling xinfony with runtime-specific code at
all.

> i have to think more before i can comment on the other stuff. what i
> started last night though is to try have a xinferno renderer in C,
> rather directly, hoping for a much easier porting to cairo/agg/whever.
> Your thinking helped me a lot, it might well be that i entered a
> dead end when trying to implement it all with haxe. It seems now
> the Renderer interface will (again) change a little, because i
> currently have some haXe constructs in it which make porting to C
> harder-- more news on that soon i hope.

Well, glad I could be of some minimal use already at least ;).

> in related news, i managed to invent a crude kludge for packaging 3rd-
> party DLLs for windows. I have to do some license checking yet, but
> i'm still hoping to get a 0.1 out over the holidays..

Looking forward to it (although I'm already tracking SVN fairly
aggressively ;)).

Dan C