silverlight thread and event-driven javascript engine (implementing trajectory playback function)_javascript skills

Case background:
The entire function is actually to retrieve data from the database and then play it on the interface. Simply put, it is similar to watching videos online and listening to music, except that what I retrieve is string data, while what they retrieve is stream data. File data. Divide the overall data into ten parts. Ten threads will fetch data from the database at the same time (concurrency increases speed) and put it in ten queues. Another thread will fetch the data from the queue and play it on the interface. You can drag the playback progress and stop it. Pause, resume playback, control playback speed. Well, the function sounds simple, and it is not difficult to do. But some problems discovered later, and digging along these problems, unearthed some things that I think are worth remembering.
Key things:
　1. silverlight background thread BackgroundWorker m_GetReplayData= new BackgroundWorker();
2. Cross-thread access to interface controls, this.Dispatcher.BeginInvoke(/Access interface UI);
3. JavaScript-style function pointer: var ShowSIngleLog = function(){} ; (on the parent page)
4. The child page registers the event of the parent page: var fatharWindow = window.opener; ;
fatharWindow .ShowSIngleLog =function (){//Play data showTrace()};
5.javascript engine thread, interface rendering thread, browser event triggering thread;
6. The browser engine is single-threaded, that is, everything is synchronized Yes, there are no two threads running at the same time
The problem:
Call the JS method through the loop of the silverlight thread to achieve the effect of playing interface data, because silverlight can only call the JS method of this page, but the track playback page It is a subpage that pops up from the main page, so I use an empty function pointer of the main page, and the subpage registers the event of the parent page to achieve the purpose of Silverlight calling the subpage method (point 3 mentioned above). After careful deliberation and argumentation, I determined that there was no problem, and there was no problem after I finished it. The local tests all used hundreds or thousands of data, and there were no big problems. Stopping, pausing, and dragging the progress had no big problems. The only problem was that the parent page interface was a bit stuck. I didn't pay attention to this problem at first. When it came to the test, more than 20,000 pieces of data were played. After playing for 5 minutes, the main interface froze. The stop, drag progress, pause, and play buttons on the track playback page all failed. The phenomenon was very strange. I once thought it was a problem with the testing machine, but finally found out that it was a problem with the large amount of data. This.Dispatcher.BeginInvoke(/access interface UI) seems to be a very simple and ordinary call, but it has two characteristics:
1. It is asynchronous, that is, it may not be executed immediately if it is adjusted, and it may not be executed immediately if it is adjusted first. Execute first, need to do synchronization control;
2. This method needs to seize the browser interface rendering thread, and this thread and the javascript engine thread are mutually exclusive.
　 With more than 20,000 data, I controlled the playback speed at the beginning , so there was no problem at first, but later a lot of data was stuck in this method, which caused the browser interface rendering thread to be constantly occupied, causing the main page to be very stuck until it was stuck. When you click on the main page, the browser event triggering thread needs to run, but the interface rendering thread is running at this time, so it is very stuck.
Solution:
　 this.Dispatcher.BeginInvoke(/Access interface UI), it is obviously caused by this thing, then find an alternative. It turns out that the data queue is placed on silverlight, but I changed it to a javascript queue. Playing data does not rely on the silver thread, and uses setimeout (this method will leak memory under IE6, so I rejected it at first) to play data regularly. The result is beautiful, the page is very smooth, there is no asynchronous problem, there is no need to control the data to be played synchronously, and it is relatively simple.
Analysis of reasons:
Why is it very stuck when playing with Silerlight, but not when playing with Setimeout? Both play continuously, and when Setimeout is playing, click on the page, and the page can also respond to events. For this problem we need to drive the javascript engine from events. The reason why the page is stuck has been mentioned above. I mainly want to explain why setimeout playback is not stuck. The JavaScript engine in the browser is event-driven. The events here can be regarded as various tasks assigned to it by the browser. These tasks can originate from the code block currently executed by the JavaScript engine, such as calling setTimeout to add a task, or It can come from other threads in the browser kernel, such as interface element mouse click events, scheduled trigger time arrival notifications, asynchronous request status change notifications, etc. From a code perspective, task entities are various callback functions, and the JavaScript engine is always waiting for the task queue The arrival of tasks. Due to the single-thread relationship, these tasks have to be queued and processed by the engine one after another. Therefore, when playing data, the operation interface will be added to the task queue and executed. Naturally, the user will feel that the entire page is no longer stuck.