Dot NET screen transmission V1.0

The last time I introduced the method of image difference comparison, I would like to further modify itAlgorithm, Using dynamic block implementation. However, the "inner feeling is not quiet" means that the screen transmission function is implemented based on the algorithm of image difference.

According to my practice, first preview:

Figure 1 screen Transmission

ProgramNote: This program is only applicable to lan. The entire program contains two parts. "Screen Sharing V1.0" is the control side, which is used to capture screen images and send the differences to the client side. The screen sharing terminal is a client that receives the screen sent by the control terminal and draws it in the current window. To achieve the effect, you must first select the "Start" button in the terminal menu, and then configure the IP information of the control end, and then select the connection to transfer the screen.

Development tools: vs. net 2008
Development language: C #
Development and testing platforms: Windows XP SP2, Windows XP SP3, and dual-core

Zheng Wen

I thought it was very simple, but it took nearly a week to write a blog from the beginning to today. Most of the time is spent on performance adjustment. Even the version 1.0 I released today is quite unsatisfactory. My screen transfer programs are divided into control and client: the control side captures the screen and then sends it to the client.

After placing the two ends on the two machines in the LAN respectively, we found that the control side occupies nearly 54 MB of memory on my experimental machine (dual-core) and the client side occupies 45 MB of memory; if the image difference is large, the control end accounts for about 20% of the CPU, while the client end may account for 50% of the CPU. If the difference is small, the control end accounts for about 10% of the CPU, the client accounts for at least 11% of the CPU. The latency of screen transmission is generally about 0.3 seconds. (The above data will vary depending on the specific configuration)

After repeated tests, it is found that the main performance bottleneck of the control end lies in the difference algorithm, because the difference algorithm takes 0.11 seconds to identify a difference (a big difference ), the while loop is used to find the difference constantly. If you try not to let the thread sleep for a certain time in the loop, the CPU will account for 70%, and my solution is to let the thread sleep for 0.1 s, however, it is obvious that 1/2 s makes the frame rate change to the original. The main performance bottleneck of the client end is the process of circular reception. I currently use the TCP transmission protocol.

Currently, screen transmission in this version is not necessarily comparable to direct whole screen transmission in terms of performance or effect (the current differential algorithm will produce a lot of fragments ), however, the bandwidth usage is significantly less than that of the whole screen during transmission. In the next step, I will mainly improve the differential algorithm and transmission process, and hope you can give more advice.

Well, there's basically so much to say. MainCodeIn the previous articleArticleIt has also been mentioned (some minor adjustments have been made for screen transmission, mainly to adjust the processing process after the difference is captured .)

Project package download: http://files.cnblogs.com/stg609/ScreenShare.rar

Author: stg609
Source: http://stg609.cnblogs.com/
The copyright of this article is shared by the author and the blog Park. You are welcome to repost this article. However, you must retain this statement without the author's consent and provide a clear link to the original article on the article page. Otherwise, you will be held legally liable.