[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-commit] gnash ChangeLog server/asobj/flash/geom/Matrix_...

From: zou lunkai
Subject: Re: [Gnash-commit] gnash ChangeLog server/asobj/flash/geom/Matrix_...
Date: Wed, 11 Jun 2008 14:48:38 +0800

On 6/11/08, Benjamin Wolsey <address@hidden> wrote:
> > Glad you see this point:)  Also, a self-designed 3*3 matrix would
> > probably faster than the generic boost template, and can be easily
> > maintained.
> >
> I'm glad you've given me the opportunity to explain the implementation
> too :)
> The boost ublas templates are, according to their own measurements,
> *marginally* slower (a few percent) than plain C arrays. In any case, to
> work on AS matrices we have to do:
> 1. as_value -> double
> 2. multiplication of all the elements
> 3. double -> as_value

I understand this. we do need a 'double' format matrix for AS.

> The boost matrix makes the implementation very minimal, as it's possible
> to have a single method for filling a matrix with an object
> (fillMatrix), and then a one-line way of concatenating them
> (ublas::prod), rather than multiplying and adding the individual
> elements.

That's the only reason I would agree to support boost here, for fast
protoype implementation.

 As said in your docs, if the bottom line of the 3*3 matrix is always
"0 0 1",  it means it is a matrix only for linear transformation, thus
not a generic 3*3 matrix. A self-designed one could still be about 2
times faster in general(even compared to generic C implementation).
Not a big deal at the moment though, if we want to speedup the VM
core, I guess getVariable/getMember should be a important place to go.

> Because matrix concatenation is very straightforward, there's not much
> risk of a slow-down there with boost. I see no need to do the
> calculations manually, because they are simple, ordinary operations, but
> take up much space when there's no doubt what they should be doing.
> As I said in one of my ChangeLog entries, Gnash is already much faster
> than the PP for matrix calculations. It's also likely that the

I would believe this. Since AS matrix in PP might be still implemented
by AS. So a C++ version would be no doubtablely faster anyway.

> bottleneck is in other operations (ptr->get_member between 6 and 12
> times for each method).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]