Jump to content

  • Log In with Google      Sign In   
  • Create Account

Display a bitmap as fast as technically possible!


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
25 replies to this topic

#1 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 14 February 2012 - 04:42 AM

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?

Sponsor:

#2 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 14 February 2012 - 05:31 PM

BUMPP

#3 mhagain   Crossbones+   -  Reputation: 7965

Like
0Likes
Like

Posted 14 February 2012 - 05:58 PM

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.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#4 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 14 February 2012 - 06:39 PM

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.

#5 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 15 February 2012 - 03:51 AM

I hate to bump again.

#6 mhagain   Crossbones+   -  Reputation: 7965

Like
0Likes
Like

Posted 15 February 2012 - 04:54 AM

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 appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#7 Nik02   Crossbones+   -  Reputation: 2829

Like
0Likes
Like

Posted 15 February 2012 - 05:42 AM

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.

Niko Suni


#8 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 15 February 2012 - 07:22 AM

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.

#9 Nik02   Crossbones+   -  Reputation: 2829

Like
0Likes
Like

Posted 15 February 2012 - 07:27 AM

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.

Niko Suni


#10 Nik02   Crossbones+   -  Reputation: 2829

Like
0Likes
Like

Posted 15 February 2012 - 07:30 AM

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

Niko Suni


#11 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 15 February 2012 - 08:45 AM

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"?

#12 Butabee   Members   -  Reputation: 236

Like
0Likes
Like

Posted 15 February 2012 - 10:14 AM

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.

#13 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 15 February 2012 - 10:28 AM

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!

#14 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 15 February 2012 - 11:30 AM

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?

#15 Chris_F   Members   -  Reputation: 2364

Like
0Likes
Like

Posted 15 February 2012 - 06:39 PM

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.

#16 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 16 February 2012 - 06:44 AM

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?

#17 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 18 February 2012 - 08:23 PM

So far we have had no progress.

#18 slayemin   Members   -  Reputation: 2554

Like
0Likes
Like

Posted 18 February 2012 - 09:36 PM

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.

Eric Nevala

Indie Developer | Dev blog


#19 David Lake   Members   -  Reputation: 118

Like
0Likes
Like

Posted 19 February 2012 - 09:13 PM

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

#20 Nik02   Crossbones+   -  Reputation: 2829

Like
0Likes
Like

Posted 20 February 2012 - 12:21 AM

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.

Niko Suni





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS