It's almost New Year's Day, and it's been a long time away from the last log writing (recently delayed for a long time to rehearse the sketch of the New Year's Day Gala ). Tomorrow, I plan to go to another place for two or three days, so I thought that I would write the screen transfer V2.0 before that, so as not to take too long, and I am too lazy to write it.
Now let's take a look:
Figure 1 screen Transmission
This figure may not show the effect intuitively, but the meaning should be acceptable.
Development Environment: VS 2008, Win XP SP2, dual-core, integrated graphics card, 1 GB memory
Development language: CSHARP
In the previous article, I shared how to obtain screen image differences in the dot net environment. This implementation is mainly based on this idea. However, some modifications were made to adapt to screen transmission. These modifications are mainly reflected in the following points:
1) instead of storing the image block data, store an image and locate the corresponding block location for comparison.
2) modify the original three assumptions as follows:
When scanning an image, first consider the area where the mouse is located as the "most likely area to change" (same as the previous article). If the scan method is called for the first time, the first line is considered to be the "most likely region to change", and then the image is scanned from left to right from top to bottom. If it is marked as "region to change ",. If the current block is not changed during the scan, the block is removed from the "possibly changed area. When the second call ScanAlgorithmThe second row is the most likely region to change, and so on. If the last line is reached, the first line begins the cycle.
Major problems encountered during the test: (Note: Only unit tests are performed, and no specific stress tests are conducted, and the test environment is not representative. Therefore, the current implementation does not guarantee its stability and reliability. These non-functional requirements will be gradually improved in the future .)
Problem description :
Local Machine (12-inch ThinkPad, dual-core p8400, 1 GB memory, integrated graphics card, 1280x800 32-bit resolution) in the test, the latency is basically milliseconds, and it feels smoother. However, when I got a Lenovo-branded desktop (17-inch 1280*1024 32-bit color, dual-core) test, the latency suddenly changed to seconds, and it felt quite slow.
cause :
the problem lies in the block screenshot. I used to store image data in blocks, and then each time I compared the data blocks, to intercept the current screen image data of the corresponding block (the screenshot uses the graphic copyfromscreen method), and then compare. This step has little impact on my current version, but the issue is apparent on a 17-inch desktop. Initially, I thought that the efficiency of the screen capture method using the copyfromscreen method was not high, so I switched to the bitblt API to cut the screen, but after the test, I found that the effect was almost the same. You can try to capture 1280*1024 images at a time and 128 pieces of image data at a time (16*8 pictures make up the image, the latter can be six to six times slower than the former ~ 8 times. In addition, the larger the image data, the more obvious the gap (that is why I did not feel it on my 12-inch book, but on the 17-inch screen ).
solution :
each time an image is compared, a full screen image is captured, then, the new and original image data are segmented and compared.
conclusion :
the problem is not terrible, but it exposes a problem in the software development process, many of my friends may have traveled the same way as me, that is, they are eager to seek success and have no concerns about unit testing. Early-Stage troubleshooting always consumes less resources than late-stage troubleshooting, sufficient unit tests before submitting Code is one of the qualities of a good software developer.
The basic process of screen transmission:
There are still many imperfections in this implementation method. For example, if a long period of time and a wide range of changes occurs, the latency will gradually increase, in addition, the CPU usage is also relatively high for a wide range of changes, which need to be further improved. In the next step, the implementation will be improved and the control function will be added. I hope the experts will give more comments ~!
Project package download: http://files.cnblogs.com/stg609/ScreenShare-v2.0.rar
Author: stg609
Source: http://stg609.cnblogs.com/
The copyright of this article is shared by the author and the blog. You are welcome to repost this article, but you must keep this statement without the author's consent and Article The original text connection is clearly displayed on the page. Otherwise, the legal liability is retained.