709726 - Open design issues for float and float4

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, enhancement)

Description

[Lars T Hansen]

This bug lists suggestions for extensions to the float/float4 spec, and issues around the current design.  One issue per comment, please.

Comment 1

[Lars T Hansen]

Forums: One call for r,g,b,a accessors in addition to x,y,z,w.  We had this in an early draft but the observation was made that the mapping of the colors to the float4 components was not always r->0, g->1, b->2, a->3, and we questioned whether there was enough utility to settle for one of them.

Comment 2

[Lars T Hansen]

Forums: Will there be any kind of integration with PixelBender?  Notably, will PixelBender accept Vector.<float4> instead of / in addition to ByteArray?

Comment 3

[Lars T Hansen]

Forums: We want fast primitives for copying from Vector.<float> etc to ByteArray and back.  In AS3/FP this will probably be handled through a general block-copy-and-convert method.

Comment 4

[Lars T Hansen]

Forums: Methods that might be useful on float and perhaps float4, both because we can provide better performance (sometimes through the SIMD units, but in general by inlining known methods aggressively) and because they are commonly used:

* clamping to a range
* linear interpolation ("lerp" in Processing)
* range translation ("map" in Processing)
* normalization of a value into a range ("norm" in Processing)
* conversion from a uint seen as a vector of four bytes to float4 and back
  (RGBA -> float4 and vice versa)

Comment 5

[Lars T Hansen]

Probably missing from the float4 spec: normalize2 and normalize3 methods.

Comment 6

[Lars T Hansen]

We probably want some sort of typedef or type aliasing facility.  The use case here is that a lot of code is currently written for user-defined data types, consider bVec3d in the Box2D code, and various Vec2/Vec3/Vec4 user types (represented as classes in ray tracers etc).  This code will be rewritten to use float4 directly but a lot of documentation will be lost if we just replace those type names in the source with "float4".

The obvious minimal solution is to allow a scoped typedef facility (we can fight about the exact syntax later):

  typedef float4 scope3d;

This means that (a) float4 has to be found as a class definition at the point this pragma is evaluated and (b) whenever scope3d is referenced in the scope it resolves to the float4 class.

For expediency we'd want to rewrite early, so scope3d boils away and does not show up in ABC content.

Some interesting edge cases:

- point3d.normalize(x) would have to have the same meaning and performance as float4.normalize(x).

- referencing "point3d" by itself should get us the float4 class

- we'd have find a reasonable meaning for how this interacts with "with".  Consider the following case:

   with ({point3d: <some object with a normalize method>})
     point3d.normalize(x)

If we rewrite early then the point3d reference in the body of the with is a reference to float4 so the object in the with is ignored.  This is not great.  But if point3d disappears from ABC content and the object does /not/ contain a point3d member then we're going to have a strange run-time error.

Probably the right solution is to rewrite early, and to disallow the code in strict mode: potential compile-time/run-time ambiguity.

(A competing proposal would be some sort of general #define / aliasing mechanism, but the issues remain more or less the same.  IMO, "typedef" is familiar to programmers and addresses the important use case without creating more complications than necessary.)

Comment 7

[Lars T Hansen]

Oliver: IDataInput and IDataOutput must somehow incorporate writeFloat4 and readFloat4, but AS3 makes this difficult.  Bug #704074 tracks this problem.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.