Silverlight thread and event-based javascript Engine (track playback function)

Background:
The whole function is actually to extract data from the database and play it on the interface. Simply put, it is similar to watching videos online and listening to music on the Internet, but what I get is string data, they take the stream file data. Divide the entire data into ten parts. Ten threads fetch data from the database at the same time (concurrency increases speed) and place the data in ten queues. The other thread extracts data from the queue and brings it to the interface for playback, you can drag the playback progress, stop, pause, and replay to control the playback speed. Well, the functions seem very simple and difficult to do. However, some problems found later, along with these problems, have been tapped into something that I think is worth remembering.
Key:
1. siliverlight background thread BackgroundWorker m_GetReplayData = new BackgroundWorker ();
2. Cross-thread access interface control, this. Dispatcher. BeginInvoke (/access Interface UI );
3. javascript function pointer: var ShowSIngleLog = function () {}; (on the parent page)
4. subpage registration parent page event: var fatharWindow = window. opener ;;
FatharWindow. ShowSIngleLog = function () {// playback data showTrace ()};
5. javascript Engine thread, interface rendering thread, and browser event triggering thread;
6. the browser engine is a single thread, that is, everything is synchronized, and there are no two threads running at the same time
Problem:
The JS method is called through the silverlight thread loop to achieve the effect of playing interface data, because silverlight can only call the JS method of this page, but the track playback page is a subpage popped up on the home page, so I used an empty function pointer on the home page to register the parent page event on the Child page to achieve the Silverlight method of calling the child page (point 3rd mentioned above ). After careful consideration and demonstration, I am sure there is no problem, and there is no problem after completion. In the local test, hundreds of data records and thousands of data records are used. The problem is not big. Stop, pause, and drag progress. The problem is that the parent page has a card, at first, I did not pay attention to this issue. More than 20 thousand pieces of data were played during the test. After playing the video for five minutes, the main interface became stuck. The track playback page was stopped, dragged, paused, and all the playback buttons expired. The phenomenon is very strange. I once thought it was a machine problem for testing and finally found it was a problem with large data volumes. This. Dispatcher. BeginInvoke (/access Interface UI) this call seems simple and common, but has two features:
1. It is asynchronous, that is, it may not be executed immediately after a call. The first call may not be executed first, and synchronization control is required;
2. This method needs to seize the browser interface rendering thread, which is mutually exclusive with the javascript engine thread.
I controlled the playback speed of more than 20 thousand pieces of data at the beginning, so there was no problem at the beginning. A lot of data was stuck in this method at the end, which led to the constant preemption of the browser interface rendering thread, the homepage becomes very stuck until it is stuck. Click the Home Page. the browser event trigger thread is running, but the interface rendering thread is running at this time, so it is very difficult.
Solution:
This. Dispatcher. BeginInvoke (/access Interface UI), which is caused by this thing. Find an alternative method. Originally, the data queue was placed on silverlight, and I changed it to a javascript queue. The playback data does not depend on the silver thread and uses setimeout (this method may cause memory leakage in IE6, so it was rejected by me at the beginning) to regularly play the data. The results are pretty, the page is smooth, and there is no asynchronous problem. You don't have to control it for synchronous data playback, which is also relatively simple.
Cause analysis:
Why is it very difficult to use silerlight for playback, but setimeout for playback? Both are continuous playback, and when setimeout is playing, you can click the page to respond to events on the page, we need to drive the javascript engine from events. The reason for the page card has been mentioned above, mainly to explain why the setimeout is not played. The JavaScript engine in the browser is event-driven. Events here can be seen as various tasks sent to it by the browser. These tasks can be derived from the code block currently executed by the JavaScript engine, for example, if you call setTimeout to add a task, you can also use other threads in the browser kernel, such as interface elements, mouse-click events, scheduled trigger time arrival notifications, and asynchronous request status change notifications. from the code point of view, the task entity is a variety of callback functions, and the JavaScript engine has been waiting for the arrival of tasks in the task queue. due to the single-threaded relationship, these tasks must be queued and processed by the engine one after another. Therefore, when playing data, the operation interface will be added to the task queue for execution. Naturally, the entire page is not stuck.