x/mobile/exp/f32: Roadmap for 1.5 release?

[sha...@gmail.com]

I've been playing around with x/mobile/gl and the exp/f32 helpers are very handy even if a bit incomplete.

What's the plan for the f32 package in relation to the 1.5 release milestone?

Is it too late to help get it into shape? Should I open issues on golang/go for any of these things?

- Consolidating with the x/image/math/f32 package

- Mat{2,3} (and probably Affine?) need to be easily convertible to []float32

- Other API improvement ideas:

  * Chaining translations like mat.Scale(...).Rotate(...).Translate(...)

  * Helpers for creating an identity Mat's (e.g. func Mat4Identity() *Mat4)

  * Helpers for loading Mat's from []float32's (e.g. func NewMat4([]float32) *Mat4)

Please let me know if there's an existing design document or roadmap for this and if I can contribute. :)

- Andrey

[Nigel Tao]

On Wed, Jul 8, 2015 at 7:13 PM, <sha...@gmail.com> wrote:
> What's the plan for the f32 package in relation to the 1.5 release
> milestone?

f32 will probably be more or less what it looks like now, since the Go
1.5 release is only a few weeks away.

Longer term, the intention is to delete that package entirely, and
replace its use by the x/image/math/f32 package, as the latter is
supposed to be the common package used by graphics and physics
packages. But filling out the x/image version (e.g. adding Mul and
Scale methods) relies on reaching consensus on how the API should
work, e.g. do methods modify the receiver, take a destination-pointer
argument, or return a new value? Once we agree what the methods should
look like, actually implementing them should be relatively trivial.
There was a brief discussion a while ago at
https://groups.google.com/forum/#!topic/golang-dev/9sYm9-2Bc2w but it
has stalled.

> Should I open issues on golang/go for any of these things?

You are free to file issues, but TBH, I don't think it'd be that
helpful. As I said, the problem is to get agreement on what the method
set should be, and the mailing list thread I linked to above seems to
me as good as place to discuss and reach agreement as any newly filed
issue would be.

> - Mat{2,3} (and probably Affine?) need to be easily convertible to []float32

FWIW, the x/image version of an Aff3 is a [6]float32 instead of a
[2][3]float32, precisely so you can slice the whole thing.

[Andrey Petrov]

There was a brief discussion a while ago at
https://groups.google.com/forum/#!topic/golang-dev/9sYm9-2Bc2w but it
has stalled.

Subscribed for updates to that thread, will keep an eye.

 

As I said, the problem is to get agreement on what the method
set should be, and the mailing list thread I linked to above seems to
me as good as place to discuss and reach agreement as any newly filed
issue would be.

Understood.

I'm not experienced enough with these kinds of packages to have strong input on The Right Way to do things, but I'm happy to help with some implementations once decisions are made.