I think if I were doing this, I would write a C++ function which converts the .NET array to a native array (of native point structs). This could be called via the Lisp native interface (exporting it via a DLL) and then use the native interface to operate on it. Allegro CL should be able to handle that part very efficiently with its built-in FFI.
Roger -------------- At 01:56 PM 12/27/2006, Edi Weitz wrote:
[Please use the mailing list.]
On Mon, 25 Dec 2006 13:17:28 -0800, "Richard Fateman" fateman@cs.berkeley.edu wrote:
We're using Allegro CL, and microsoft's ink routines, which ultimately return to us "strokes" which we can decompose as arrays of points, each containing an X and a Y.
This decomposition, as we have written it, crosses the lisp - .net boundary too often. Presumably with the right magic, we can just access the arrays once. Suggestions? (I'd rather do this extraction in Lisp....)
;;; Here's our way convert a stroke to a list of (x . y) points.
(defun decode-one-stroke (as) ;a stroke (let ((netarray [GetPoints as]) (list-of-points nil)) (do-rdnzl-array (v netarray (nreverse list-of-points)) (push (cons [%X v ][%Y v]) list-of-points) )))
Have you tried "direct calls"?
This might yield a noticeable performance gain, but the main problem of crossing the boundary too often will still be there.
Right now, there's no way to overcome this. You'd have to write low level C++ code using something like (the equivalent of) LispWork's WITH-DYNAMIC-LISP-ARRAY-POINTER on the Lisp side to get a .NET array into the Lisp world in one fell swoop. But this would solve only half of it, as you'd still have to get at the x/y coordinates of each point, crossing the boundary once again. ATM I have no idea how a general solution could look like.
Cheers, Edi. _______________________________________________ rdnzl-devel mailing list rdnzl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel