Texture.ReadData minimum pitch (DX9)

[GoogleCodeExporter]

I noticed that with a texture of the size 10 the write and read methods are 
not going right anymore. I think this is a bug. When set to 16 or more, it 
does work. It seems like the pitch cannot go smaller then 64.

Original issue reported on code.google.com by slaait...@gmail.com on 19 Feb 2009 at 8:30

[GoogleCodeExporter]

First, there is no Texture.ReadData. Secondly, your description of the issue is
cryptic. What is a "texture of the size 10"? When you say that "the write and 
read
methods are not going right anymore", what exactly does that mean?

Original comment by Mike.Popoloski on 25 Feb 2009 at 7:24

[GoogleCodeExporter]

Ok. I mean when the Texture is locked with a specific Rectangle it returns a 
DataRectangle. This dataRectangle it's pitch is not right, according to the 
given 
rect to lock to. 

If the size of the texture itself is smaller then 10, the pitch is always bound 
to 16 
* the bytes used, instead of 10 * the bits used (in my case, r32f, 16*4 = 64) 
while 
it should be 10*4 = 40.

is this a bug?

Original comment by slaait...@gmail.com on 25 Feb 2009 at 8:01

[GoogleCodeExporter]

Why would the pitch ever change to mean the number of bits used? The DirectX 
docs
state that pitch is the number of bytes in a row of the surface. So if your 
texture
has a width of 10, it should return 10 bytes. Also, the pitch is very dependent 
on
the format of your texture data.

Original comment by Mike.Popoloski on 25 Feb 2009 at 8:43

[GoogleCodeExporter]

but that is what i am stating. I was using a texture of the size 10x10 and the 
pitch 
was the size of 64. The bytes usage was 4 per pixel meaning it was a pitch for 
16 
pixels.

Second i thought the returned pich of a locked texture by rectangle would 
result into 
the data that was inside the given rectangle.

Original comment by slaait...@gmail.com on 25 Feb 2009 at 9:32

[GoogleCodeExporter]

Please note that pitch and pixel size are not necessarily the same. The pitch 
is the
number of bytes between successive rows of data, but it is not the case that 
all of
that data is actual image data. The extra bytes in the row are typically there 
for
optimization purposes, to pad out the size in bytes of a row to a power of two.
That's what is happening here: your image is 10x10x4, so a row of pure image 
data is
40 bytes. The next available higher power of two is 64. The trailing 24 bytes 
of data
are padding you must ignore when reading the locked data. This is why the 
runtime
provides you the pitch -- you need both the pitch and the image width to 
iterate over
the pixels of the image.

It could also be the case that the runtime resized your texture when you loaded 
it.
You need to explicitly pass flags to the D3DX loaders to tell them to keep the
texture as a non-power-of-two. 

Neither of these are bugs in SlimDX or D3D.

Original comment by josh.petrie on 26 Feb 2009 at 5:11

• Changed state: Invalid