• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
David Lake

Display a bitmap as fast as technically possible!

25 posts in this topic

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

Share this post


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

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.
0

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.
0

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.
0

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.
0

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.
0

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

Share this post


Link to post
Share on other sites
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"?
0

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Regarding partial surface updates:

The common need to update just specific rectangles of a graphics memory area is the specific reason why D3D Lock* and Update* methods have rectangles as parameters. It is simply more efficient to just copy the actually changed data than blindly copy it all (if you can efficiently detect the changed areas).

It isn't very difficult to detect what specific areas of a desktop have changed, and express the changed areas as lists of rectangles. If you capture and send the images within those rectangles, the combined amount of data is likely much smaller than what the full desktop image requires.

On the drawing side, only draw the data that you actually get. And if you don't have all the data that you need to fill the frame, request the full frame image (commonly known as keyframe) from the remote desktop server and track changes from that.
0

Share this post


Link to post
Share on other sites
If i can calculate the difference between the current and last frame and set the alpha as well as rgb channels of the unchanged pixels to zero so the unchanged areas can be compressed out by the png compression then just lay the new frame over the last one at the other end.
0

Share this post


Link to post
Share on other sites
something like this:
[code]Parallel.For(0, bmp.Height, i =>{
for (int j = 1; j < bmp.Width; j++){
if (bmp.GetPixel(j, i) == _currentbmp.GetPixel(j, i)){
bmp.SetPixel(j, i, Color.FromArgb(0, 0, 0, 0));
}
}
});[/code]

it looks like I dont even need to change the recieving end as the image is drawn over the old one and the transparent parts will show the unchanged pixels on the old image I just need to make my loop work.
0

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0