The current behavior, (in IE anyway) seems to be to wait until your application becomes idle (ceases execution on the UI thread). So when I'm doing startup computations on the UI thread, and I send a request to the server and expect to process it in the
background thread in parallel, what actually happens is the startup computations finish first, then the request is sent, then the program waits for the response, and finally the response is processed in the background thread, all in serial, taking nearly
twice as long to complete the initial startup.
Is this acceptable behavior? You can kind of get around it by breaking up the startup computations so everything after the request is sent happens from an event handler on a timer. i.e. force execution to stop on the UI thread long enough so the request
can probably be sent, then resume execution. I found I could use a timer interval of 8 seconds (force 8 seconds of doing nothing, before any of the UI has even loaded) and actually speed up the initial startup by completing the rest of the work in parallel.
I don't like it at all. I was not in favor of adding synchronous (blocking) web requests to silverlight, but I've changed my mind. I bet a synchronous request would actually hold up the UI thread for less time in my application.
This is the current behavior. It calls the code on the UI thread. You can use a BackgroundWorker to use a 2nd thread if you want. But I think this is not as bad as it sounds. Much of your UI thread could be in a wait state and since the Browser network
stack limits the number of out-bound requests, I don't think this is delaying it as much as you think.
(If this has answered your question, "Mark as Answer")
Shawn Wildermuth
C# MVP, MCSD, Speaker and Author
Silverlight 3 Workshop
Miami, FL: Oct 12-14th
Portlant, OR: Dec 2-4th
Atlanta, GA: Dec 7-9th
http://silverlight-tour.com
Thanks for your reply, but I'm afraid I don't understand you.
I moved the whole WebRequest.Create() and BeginGetResponse into a background thread. This had no effect at all. No request is sent until the UI thread is in wait state.
I'm guessing what's happening here is the underlying send async request method provided by the browser must be called on the UI thread, and so silverlight dispatches the call, meaning it won't run ever unless the UI thread becomes idle. At least I hope there's
a reason that good.
I don't like it. But it seems that's what we're stuck with.
I was not in favor of adding synchronous (blocking) web requests to silverlight, but I've changed my mind. I bet a synchronous request would actually hold up the UI thread for less time in my application.
This is a requirement imposed by the browser plugin APIs. If the service requests could be initiated/completed on any thread, then implementing sync behavoir could have easily been done via wait events. Glad to hear you've changed your mind though. :)
I was not in favor of adding synchronous (blocking) web requests to silverlight, but I've changed my mind. I bet a synchronous request would actually hold up the UI thread for less time in my application.
This is a requirement imposed by the browser plugin APIs. If the service requests could be initiated/completed on any thread, then implementing sync behavoir could have easily been done via wait events.
Glad to hear you've changed your mind though. :)
Well, Jack, one mind at a time. I was originally against it, and you helped me clear my mind, so there's hope out there(lol).
Eloff
Member
139 Points
114 Posts
Did you know silverlight 2b2 does not send a web request when you call BeginGetResponse ?
Sep 08, 2008 06:59 PM | LINK
The current behavior, (in IE anyway) seems to be to wait until your application becomes idle (ceases execution on the UI thread). So when I'm doing startup computations on the UI thread, and I send a request to the server and expect to process it in the background thread in parallel, what actually happens is the startup computations finish first, then the request is sent, then the program waits for the response, and finally the response is processed in the background thread, all in serial, taking nearly twice as long to complete the initial startup.
Is this acceptable behavior? You can kind of get around it by breaking up the startup computations so everything after the request is sent happens from an event handler on a timer. i.e. force execution to stop on the UI thread long enough so the request can probably be sent, then resume execution. I found I could use a timer interval of 8 seconds (force 8 seconds of doing nothing, before any of the UI has even loaded) and actually speed up the initial startup by completing the rest of the work in parallel.
I don't like it at all. I was not in favor of adding synchronous (blocking) web requests to silverlight, but I've changed my mind. I bet a synchronous request would actually hold up the UI thread for less time in my application.
-Dan
swildermuth
Star
8438 Points
1547 Posts
Re: Did you know silverlight 2b2 does not send a web request when you call BeginGetResponse ?
Sep 08, 2008 07:14 PM | LINK
This is the current behavior. It calls the code on the UI thread. You can use a BackgroundWorker to use a 2nd thread if you want. But I think this is not as bad as it sounds. Much of your UI thread could be in a wait state and since the Browser network stack limits the number of out-bound requests, I don't think this is delaying it as much as you think.
Shawn Wildermuth
C# MVP, MCSD, Speaker and Author
Silverlight 3 Workshop
Miami, FL: Oct 12-14th
Portlant, OR: Dec 2-4th
Atlanta, GA: Dec 7-9th
http://silverlight-tour.com
Eloff
Member
139 Points
114 Posts
Re: Did you know silverlight 2b2 does not send a web request when you call BeginGetResponse ?
Sep 09, 2008 12:42 AM | LINK
Thanks for your reply, but I'm afraid I don't understand you.
I moved the whole WebRequest.Create() and BeginGetResponse into a background thread. This had no effect at all. No request is sent until the UI thread is in wait state.
I'm guessing what's happening here is the underlying send async request method provided by the browser must be called on the UI thread, and so silverlight dispatches the call, meaning it won't run ever unless the UI thread becomes idle. At least I hope there's a reason that good.
I don't like it. But it seems that's what we're stuck with.
jackbond
Contributor
5704 Points
1515 Posts
Re: Did you know silverlight 2b2 does not send a web request when you call BeginGetResponse ?
Sep 09, 2008 01:51 AM | LINK
This is a requirement imposed by the browser plugin APIs. If the service requests could be initiated/completed on any thread, then implementing sync behavoir could have easily been done via wait events. Glad to hear you've changed your mind though. :)
Khet - The first Silverlight multiplayer game
Zork I: The Great Underground Empire
samcov
Participant
1629 Points
697 Posts
Re: Did you know silverlight 2b2 does not send a web request when you call BeginGetResponse ?
Sep 09, 2008 03:05 AM | LINK
Well, Jack, one mind at a time. I was originally against it, and you helped me clear my mind, so there's hope out there(lol).
Sam...