Matrix utilities into a separate library

[Pekka Paalanen]

Hi,

I was looking for a nice and small C library for static sized matrix
algebra and inversion, especially 4x4 matrix inversion. I didn't find
any. OTOH, everyone has a C++ library or two.

However, the Math utilities part of Cogl looks perfect for my use, with
its specialised inversions for different classes of 4x4 matrices. I
just do not have use for the rest of Cogl, as the intention is to use
OpenGL ES 2 as is. Maybe there are also others looking for a small
matrix library for use with 3D projective coordinate systems...

Therefore I would like to suggest separating the Math utilities, or
just the matrix API, into a completely separate library, independent of
the rest of Cogl. It won't help my current needs, but might help in the
future.

Cheers,
pq

[Robert Bragg]

Yeah, we'd be happy to enable the math apis to be used on their own.

Instead of splitting the whole api out into a separate project/repo though I think our preferred approach would be to spin the apis into a sub-module of the cogl-project, like we have cogl-pango which is an optional support library. We could then expose configure options that would allow you to only build the cogl-math sub-module if that's all you really want.

This approach would avoid us having to maintain, package and release a separate project and avoid needing a shim over a new standalone api for compatibility. Projects could  then just check for a cogl-math pkg-config file if they want to use this sub-library.

Hopefully that sounds reasonable to you?

Actually we'd quite like the opportunity to iterate some parts of our matrix api, so actually breaking the api into a separate module could be a a good time to do that. For example one thing we were thinking of is reducing the size of CoglMatrix to remove the padding for caching the inverse matrix. I'm not convinced that optimization has really payed off. It's something we copied from Mesa, assuming if it was worthwhile for them then it would be good for us too, but we now think that probably this kind of caching can be handled in higher levels if required.

kind regards,

- Robert