It is admittely unfortunate that D3D does not supply this as a convenience (with, for example, something like UpdateSurfaceFromMemory), since it supports similar operations with texture creation.

There are many different 32bit, don´t know which is which. But did like this:

private static BitmapSource JpegToBitmap(byte[] jpg)
{
using (var ms = new MemoryStream(jpg))
{
JpegBitmapDecoder decoder = new JpegBitmapDecoder(ms, BitmapCreateOptions.PreservePixelFormat, BitmapCacheOption.Default);
BitmapSource bitmapSource = decoder.Frames[0];
FormatConvertedBitmap newFormatedBitmapSource = new FormatConvertedBitmap();
newFormatedBitmapSource.BeginInit();
newFormatedBitmapSource.Source = bitmapSource;
var pixelformat = new System.Windows.Media.PixelFormat();
pixelformat = PixelFormats.Pbgra32;
newFormatedBitmapSource.DestinationFormat = pixelformat;
newFormatedBitmapSource.EndInit();
return newFormatedBitmapSource;
}
}

And for the Lock, is this okay:

Before Loop

var lockedtex = texture.LockRectangle(0, LockFlags.None);
var rec = new System.Windows.Int32Rect(0,0,0,0);

.........

.....

...

Loop

var BitmapSource = JpegToBitmap(TextureData);
texture.LockRectangle(0, LockFlags.Discard);
BitmapSource.CopyPixels(rec, lockedtex.DataPointer, 0, lockedtex.Pitch);
texture.UnlockRectangle(0);

But i do have a problem, it seems my decoding is failing, but i can´t see the problem.
I get (No imaging component suitable to complete the operation was found).

First result from google.

But i am only using MemoryStream in one place, i can´t really set the position as it isn´t even used like that.

The error occurs here:

texture.LockRectangle(0, LockFlags.Discard);

but only if i put it after: var BitmapSource = JpegToBitmap(TextureData);

You only want to hold the lock for the duration of the copy, not a moment longer. Locking means that the system cannot access the resource (while you are accessing it), and therefore keeping it locked will effectively stop rendering for the duration of the lock.

If the D3DX loader can open your jpeg file, then the data itself is probably ok. But, do you have all the jpeg data in the buffer before you decode it? Have you verified it? You could write the jpeg from your byte array to a file and see if you can open it in other programs.

The JPEG decoder is standard issue on .net installations, so the problem is not likely related to it being absent.

Yes should be, did this to test it:

        private static BitmapSource JpegToBitmap(byte[] jpg)
        {
            using (var ms = new MemoryStream(jpg))
            {
                JpegBitmapDecoder decoder = new JpegBitmapDecoder(ms, BitmapCreateOptions.PreservePixelFormat, BitmapCacheOption.None);
                BitmapSource bitmapSource = decoder.Frames[0];

                FormatConvertedBitmap newFormatedBitmapSource = new FormatConvertedBitmap();
                newFormatedBitmapSource.BeginInit();
                newFormatedBitmapSource.Source = bitmapSource;
                var pixelformat = new System.Windows.Media.PixelFormat();
                pixelformat = PixelFormats.Bgra32;
                newFormatedBitmapSource.DestinationFormat = pixelformat;
                newFormatedBitmapSource.EndInit();
                using (var fileStream = new FileStream(@"C:\Testfile.bmp", FileMode.Create))
                {
                    BitmapEncoder enc = new BmpBitmapEncoder();
                    enc.Frames.Add(BitmapFrame.Create(newFormatedBitmapSource));

                    enc.Save(fileStream);
                }
                return bitmapSource;
            }
        }

Tested both before pixel conversion and after. Both works perfectly, saved bmp file that can be displayed without problem.

It is admittely unfortunate that D3D does not supply this as a convenience (with, for example, something like UpdateSurfaceFromMemory), since it supports similar operations with texture creation.

I think it does: Surface.FromFileInStream. Never used, but it should support jpg according to the underlying D3DXLoadSurfaceFromFileInMemory

Oh, I forgot that

This would be the easiest way to get the JPEG data to the surface.

Wait, can i use this or what?
If it´s easier and do the same thing, and of course, isn´t slower or stuff like that. I am more than happy to use it:)

If it works it sure is the simplest to implement (no need to pitch or maybe even swizzle the color channels, which can mean some pointer hassling). Can't speak for the jpeg decoder, but since everything will now happen natively you could actually gain some performance.

Nice, but ehm, i need a surface?
How does that work, as i am currently working with Textures?
So confused how to implement it.