"I dont agree. I can write a program that will keep any size texture in memory that I want it too. The computer itself doesnt care what size the texture is. Poser itself might do this but it has nothing to do with the way computers work." (and some subsequent posts...)

Agreed. I was being a bit too generalistic, in the interests of simplicity.

I'm not 100% sure of this (it was a long time ago) but IIRC there's a "Block Copy" instruction for the Intel instruction set that takes as one of its modifiers a number that is, effectively, the "power of 2" number of bytes to copy. Since it is a single machine instruction it operates considerably faster than a loop of several single-byte (or word) machine-code copy operations.

That was then. Things may have improved since. But much of the "legacy" code that still abounds in Poser (and many other apps that need to move large lumps of data around - including Windows) make use of the "low-level" functions that utilise this facility.

That was what I meant by "the way computers work". Moving in "powers of two" is (often a lot) faster than moving arbitrary amounts on arbitrary byte boundaries. Its the usual trade-off between speed versus memory.

That's all..

Cheers,
Diolma