[Papervision3D] Optimizing performance: anything else I can do?

[John McCormack]

It's probably to do with the underlying nature of the electronics:

The early PCs were 8 bit computers, so you had 8 bits of wire on the 
data bus (1 byte) and you could send 8 bits at a time from cpu to memory.
16 bit Windows 3.1 worked with 16 bits of wire on the data bus (2 bytes)
Now we have 64 bits.

On a 32 bit data bus, imagine having to write a 33 by 1024 pixel bitmap 
into graphics memory.
Now we want to write 33 bits, so you write one 32 bit (4 byte) integer 
('int') followed by 1 more bit because it's 33 bits wide. You have to do 
this 1024 times because of the depth.

What makes it worse is that you want to leave alone the other 31 bits of 
the destination 4 byte integer, so you get the destination integer, mask 
off the 31 bits, write the single bit into the zero position of the 0 to 
31 bit integer and then send it back.
Of course much of this is done automatically, now, in the hardware.

But even a 32 bit integer may be inefficiently written:
Consider memory starting from the 4 byte, 32 bit, memory address
0000 0000 0000 0000 0000 0000 0000 0000, the place for the next 32 bits 
would be
0000 0000 0000 0000 0000 0000 0000 0001

Let's say you want some of these 32 bit at the first address address and 
some at the second. So now one memory access is not enough.
If things were lined up for efficiency you would make sure your block of 
data (our integer) did not straddle two addresses.
C and C++ allow you to set the alignment.

Now imagine writing a 34 bit integer that straddles 3 addresses:
1 bit at the 31st position of some address
32 bits at the next address
1 bit at the next address

That's a lot of work, mainly due to the nature of the underlying 
electronics.
There may be other issues and some of the ones above may no longer be 
relevant.

John

Alan Pinstein wrote:
>> I believe it's good practice to keep bitmap dimensions to x2 
>> (64,512,etc) - not sure how much performance boost you'll get from 
>> that one tweak tho.
>
> Why? From everything I've read the point of this is simply to benefit 
> from Flash built-in mipmapping. Outside of that I know of no reason 
> why this matters (yet).
>
> If it's just mipmapping, then this can't possibly have an effect at 
> full-screen for my application since none of my textures ever get 
> "shrunk" in the viewport.
>
> Alan
>
> _______________________________________________
> Papervision3D mailing list
> Papervision3D at osflash.org
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
>