Jump to content
  • Advertisement
Sign in to follow this  
David Lake

Display a bitmap as fast as technically possible!

This topic is 2490 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I need to display a bitmap as fast as possible, will dx be faster than .net 4 GDI?
This is my syntax:
accept connection on a listening socket
recieve a bit of stuff including image dimentions
create a dx device if dx is faster than gdi
start a loop
get the bitmap from the socket
show the bitmap
loop again

with gdi it takes an imense 100ms to splash out a bitmap on a picturebox in a form i have had limited success with slimdx dx9 and the image got streched and distorted and the bitmap keeps getting corrupt and dx throws an exception and yes i have a loop for the socket.receive.

So then can someone give me some plain simple and dirty samples i can try?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Also consider whether advanced window frame effects (such as shadows and transparency) are actually needed, given your business requirement?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!