Display a bitmap as fast as technically possible!

BUMPP

OK, you've got a number of possible bottlenecks here. Using a D3D approach, creating a device is going to be quite a slow operation (relatively speaking) so that's a once-off overhead that you'll need to accept. Secondly, you need to define what's involved in your "get the bitmap" step. Are you reading it from disk? From memory? Across a network? Thirdly, using D3D you'll need to create a texture and load the bitmap data into it although the first part of that can be optimized out if e.g. the bitmap size hasn't changed since last time you showed one. Fourthly the size of your bitmap will have a large bearing on how fast the entire operation can be completed.

All of these will take more time that the actual act of showing the final bitmap on screen, irrespective of whether you use D3D or GDI. Showing an image on screen is fast - the laptop I'm using at the moment can do that several thousand times per second. Getting it from source to a format that can be shown on screen is the slow part and that's the part you need to focus on optimizing.

So like I said you need to give info on what's involved in your "get the bitmap" step before anyone can really start providing answers.

Sorry I should have mentioned its a screenshot captured from one pc using getfrontbufferdata with slimdx dx9 and sent over a socket in a loop and wont vary in size.

I hate to bump again.

There's your bottlenecks right away. In the DirectX SDK GetFrontBufferData has the following note appended: "This function is very slow, by design, and should not be used in any performance-critical path".

The network will also be a bottleneck here - a 1280x1024 screenshot will be about 5mb in size so even on a 100mbit local LAN you're looking at about half a second to transmit it - and that's assuming no other traffic or overhead (which there will be).

I think you may be already at peak performance here.

It is best to tackle the problem set piece by piece.

For example, first optimize getting the render results to the main memory as fast as possible. If you can modify the source program, use render-target textures instead of GetFrontBufferData (and preferably D3D11 hardware/api).

You can also optimize the data transfer independently of the image source - just send random frames over the network. If you haven't already, consider compressing the data before the transfer. If you can afford to lose some fidelity, a MPEG-style video codec could be useful. And if you need full fidelity, compress the individual frames using PNG before sending (though if the compression is more inefficient than the raw send, don't bother).

Live video streaming is a very difficult subject, and there is always some latency and/or bandwidth issues; especially if you play fast action games over such video terminal. With movies and other static video, you can hide latency because the delay of the image or sound is not dependent on immediate user input and therefore you can compensate for it.

Its a client server remote control program I have no alternatives because i need the client to be controlled to connect to the server controlling it, its for a mates pc repair business, so obviously its a desktop capture and yes i know i can do it faster with GDI but that dont get the windows effects like the ghost of a file while dragging it, i am using png which makes a 1280x1024 capture about 200KB but as you say Nik02 its slow, and another thing the client has to be as compatible as possible as the clients pc may be quite old.

For desktop capture, you could detect the regions (list of rectangles) that have changed since the last frame and only send them instead of sending the full frame each time. This is how Windows RDP works in the "compatibility" mode. In Windows RDP "advanced" mode, some graphics commands are relayed to the RDP client and are executed as late in the chain as possible and/or practical.

Also consider whether advanced window frame effects (such as shadows and transparency) are actually needed, given your business requirement?

When files are dragged and go semi transparent they cant be seen with the GDI screen capture method and how would i go about partial updating "list of rectangles"?

As far as the get bitmap part goes, which I think you mean upload to gpu, the fastest method would probably be to copy portions of it over a few frames. Maybe like 1/4th of the image a frame. I haven't use .net GDI but I've tried it with directx and if you write your data to a staging texture, then copy it to a gpu only texture it's pretty fast. Use UpdateSubresource for the copy from staging to gpu texture.Whoops, sorry glazed over that you're using dx9... what I said only works in dx10, but technically, I think the same concept would go for dx9 but with different functions.

I can use DX10 on the host side to display it I just need the client side capturing it to be as compatible as possible, you will have to be a pinch more detailed than that i'm like a new born baby when it comes to coding DX.
I've exhausted google this is like a wild goose chase im going round in circles!

Using procexp and procmon i can see the WINMM.dll MCI API DLL seems to handle a print screen keypress and print screen gets all the transparent windows effects i wonder if i could use this somehow to trigger and grab a printscreen directly?
I just noticed the dwm does the screen capture so is there a simple way of using that?

Well, you could start by using a lossy compression, otherwise PNG tends to be a slow compression and only beats other compression algorithms like LZW by a small amount. You could reduce your color depth to RGB565 or RGB332. You could also take the current frame and the previous frame and perform a difference operation on the two, then compress and transmit that instead.

I have been reducing the color depth but it dont make much dif and i tried saving screenshots in different file formats and png is much smaller than even jpg for the quality, that difference thing sounds good but whats the point when i would still be sending the whole image?

So far we have had no progress.

Step 1 in my requirements gathering process is to ask this question: Is there software that someone else has already created which does what I need to do?

There's a lot of remote control software out on the market specifically for remote assistance. I think you'd probably end up saving a lot of time and money if you downloaded/purchased an existing software solution and you'd have a higher level of quality assurance.

There is no program that does this thats free I have looked and also I WANT to doo this to learn!

Do note that time is also a scarce resource, and is seldom free.

I do appreciate that you want to learn this stuff anyway, but then you have to be willing to invest unknown amount of time into the project - you don't know when you're ready until you actually are ready.

Again, approach the problem systematically, piece by piece, and then finish the puzzle when you have all the individual pieces at hand. You don't need all the pieces to begin solving it, though.