Doug Twilleager wrote: > Efficient usage of some of the new data movement extensions is > also very > application dependent. We are looking at ways to incorporate it into > the API though.
It seems for me that java3d should get it for free. Normally, opengl driver cannot do this automatically, because in theory, array contents can be changed by application just after returning from opengl call. But with GeometryUpdater, I think that java3d has strict control over array mutability (in theory at least:). It would be nice for java3d to expose some nio utility methods - for example, small malloc-like utility from which user would request a bit of native memory, in normal or in AGP space (of course by some opengl-like frequency hints, not just MEMORY_AGP). Java3d would organize this memory and maybe even do compaction - if buffers would be behind wrappers, address change could be transparent. Only requirement would be that such buffers could be modified only from GeometryUpdater (and possibly from SomethingUpdater which could be used for images). Back to question - what makes using asynchronous transfer impossible in current java3d ? Isn't GeometryUpdater control enough ? Artur =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
