Re: [Openvrml-develop] Our SFImage story

[Braden M. <br...@en...>]

On Wed, 20 Dec 2000, Christopher K. St. John wrote:

> Braden McDaniel wrote:
> >
> > In either of those cases, our current design would require dynamically
> > converting to the 4-byte-element format when one of these bindings
> > attempts to access the data.
>
>  The java bindings (EAI and Script node) already use an array
> of bytes.

Both the IDL and Java bindings to the EAI use int. (Perhaps you were
thinking of the obsolete Cosmo EAI?) This makes the Java Script node
binding the oddball (which is also the case in respects other than this
one).

> The netscape javascript api, if I'm remembering right,
> lets you fiddle with the array access operators in the code
> that binds the script object to the underlying C/C++ object.
> You'd case out on numcomponents, but it shouldn't be very much
> code. (That assumes I'm remembering correctly...)
>
>  Besides, doing image processing in javascript is not likely to be
> fast for a whole raft of other reasons, so I don't see it as a likely
> bottleneck.
>
> > I think we need to store the integer format in VrmlSFImage.
>
>  Then you'd have to convert back and forth to an array of bytes
> when you were using a java interface.

Yup. To make this a little less painful, the Java binding could cache the
byte data. And as I mentioned before, we can go ahead and cache this data
in VrmlSFImage for the time being.

(As far as caching the byte data in the renderer, we really need to do
that too: the data used by the renderer may be rescaled from its original
dimensions, and that should be opaque to the scene graph interface.)

>  Unless it turns out that the javascript implementation is
> just totally undoable, I'd vote for leaving things the way
> they are.

It's not impossible, and if the ECMAScript binding were the oddball here,
I'd agree with you. But the Java binding is the oddball.

-- 
Braden N. McDaniel                              e-mail: br...@en...
<http://endoframe.com>                          Jabber: br...@ja...