[sldev] Re: Optimizing OpenJPEG (oprofile kicks ass)

[Argent Stonecutter]

> Stefan Westerfeld wrote:
>>> doing my math right. Christ. So, I'm looking in to making them
>>> dynamically allocated, I don't see slviewer ever using more than  
>>> 64x64
>>> (33kb!).

> Be careful.  There's two good reasons not to code SL specific
> optimizations into openjpeg.

> 1.  They won't be accepted upstream.  That means constant
> merging/backporting.
> 2. If you violate the spec you may violate the patent license.

Depends on how the code works. If it's possible to tell how big these  
arrays need to be ahead of time in a completely reliable manner that  
doesn't assume any special knowledge related to SLViewer, then it's  
not an SL-specific optimization and doesn't violate the spec.

Also applies to Callum's comment.

Given the magnitude of the savings, it would probably even be  
worthwhile to assume a small ... even fixed size ... array and copy  
to a larger one if the assumption proved false, the way dynamic  
string allocators commonly do.

By the way:

> Oh boy are dynamically allocated multi-dimensional arrays fun to do in
> C. ;P

One hopes this doesn't mean you're creating a vector of pointers  
rather than replacing foo[a][b] with foo[a*stride+b]. Or foo 
[(a<<log2_stride)+b] with appropriate care that stride is a power of  
two. :)