What the? TextureFromBitmap lag!!!

The problem is that the .net framework is doing bounds checking for each individual pixel, and this is slow.

To speed things up, you could make an empty texture, lock it to get the pointer to it's data, lock the bitmap also by using Bitmap.LockBits, and copy the bitmap data to the texture scanline by scanline.

To use pointers in c#, you need to create an unsafe block in order to gain access to the raw data without bounds checking. In VB, you'd have to copy the data via an array, (easily done by using the services of the Marshal class) since VB doesn't have a mechanism to dereference pointers directly.

I'm not sure if its bounds checking but its something to do with the way the VS2.0 debugger interacts with the PInvokes that are happening. There are 512x512 GetPixel calls happening and the debugger is checking things each time. Specifically its to do with the MDAs. Turning off the MDA in VS like we do with LoaderLock just prevents it from being reported, it does not stop the checking code from running.

Start your app with ctril-f5 (start without debugger) and the problem will go away.

The bug is documented here and here but there is no resolution. However there is a way you can turn off MDAs in a config file that should give you a workaround.

Thanks guys. I saw some other code that locked both buffers and transferred that way and so I implemented that and got a mismatch in color data types.

I would do the buffer to buffer copy using unsafe code but I'm unsure what will happen with other bitmap formats. I'm building a routine to help developers and want to let them choose what format to use.

Funny thing is, like you said TheZBuffer, I used the same lock to lock routine but didn't lock the bitmap and just used the get pixel and still got the lag. So I am going to say that TheZBuffer is right about the getpixel part of the bitmap code. I don't think it has to do with directx but dotnet.

the bitmap's getpixel routine converts from whatever format so that would be what I would like to use, that said, if I turn MDA's off what will slip by? Anything too impartant? Perhaps a newbie question but still.

-Devin

When i had that problem, i switched over to the D3DX functions in TextureLoader. (FromFile).
Not sure if that'll help you - depends on where your bitmap data comes from. Even if its in memory, you might be able to use the FromStream method.

Wyzfen

devronious: We are all 100% are that this is a .Net problem. Its documented well on those MSDN bug report links and at the time it was originally reported we had several back at forth conversations with the MDX team and the VS team.

This one has come up several times here and on MSDN so I've FAQ'd it

Why is Texture.FromBitmap so slow in .Net 2.0

If you turn off MDAs then you are back where you were with VS2003. You can check the list of things they look for on MSDN. If you need Texture.FromBitmap though you really have little choice because its unusable for anything but the smallest texture.

Anybody tried the FromStream method that WyzFen suggested? And if so what about pixel formats and conversion?

-Devin

I used FromStream and it worked great. I just saved the bitmap to a memory stream, set the position to zero, and handed that stream to FromStream. It seamed to be as fast as FromFile. I used this for generating font textures at start-up, and I hardly notice any lag.

Can I ask how you did the FromStream method. I'm getting errors trying it. And I seem to have to deal with formats. Can you show me how you avoided it?

Thanks,

Devin

This is basically how I did it:

snap... I did just about the same thing but specified a size in the memory buffer constructor that I got from calcing the bpp against the bitmap size, thus why I was using the format data (to determine the bpp). I didn't put 2 and 2 together from the docs that you could do a default constructor for that. Thanks,

Devin

I'm still getting lag with this method as well.

Can you work out in which call the lag is ?
Could be the original bitmap loading, the bitdepth conversion, loading it to the stream, or the FromStream call.

Zbuffers' link looks interesting - i know that i'm not having any issues using TextureLoader.FromFile however, so i'd guess the problem isnt with the FromStream call. Can you post your code ?

In my code, i load the images from disk (not memory), so i just use TextureLoader.FromFile and dont use Bitmap objects directly.

Wyzfen