On 03/05/20 7:22 pm, Nicolas Cellier wrote:
> More than often, the data transfer can handle offset and stride via a 
> BitBlt tricks (unless we have an odd layout).
> This enables extracting a single "column" or bloc of data from a big 
> file with a single copy.
> I may need to extend BitBlt to cope with all the available bit-widths, 
> not just 8 (byte) or 32 (word) though.
> 
> Also, those formats offer packed and contiguous memory layout which is 
> an advantage too when dealing with large chunks of data.
> Especially if we have vectorized primitives operating on the arrays.
Ha! Now I get it. But FixedWidthBitArray is too primitive a type for 
this purpose. It would expose host's word size to class methods instead 
of encapsulating it in plugins.

I would apply recursive decomposition and use something like 
PackedVector(stride, length) on the lines of a Form(width, height). 
PackedVectors may decomposed into smaller packedvectors recursively 
until they are small enough for ImmediateClass (i.e. stride = host's 
word size). This would be well-suited to speed up through arch-specific 
plugins.

When loading a packedvector from an image on a smaller word size host, 
ImmediateClass elements could be converted into packedvectors. The 
reverse could happen on larger word size hosts with a one-time 
conversion cost.

Regards .. Subbu