When using Wpf.WebView.LoadHtml to load the following sample, the image from the file system (test.jpg) does not load but the http image does.



It works correctly when saving the html to a file and using WebView.Url to load the html file.

I am wishing to use RegisterResourceHandler with the local file links, this currently works when loading a file using WebView.Url but not when using WebView.LoadHtml.

Thanks
Tim

Thanks for the update

Thanks, this works fine. But...

When using LoadHtml in conjunction with a ResourceHandler, it appears to load the html very slowly (the html is a simple list of 15 images). My resource handler is matching all urls that end in ".jpg" so I can load images from a custom stream.

If I return true from ResourceHandler.Match, it takes nearly a second before the next Match call is made.
If I return false from ResourceHandler.Match, the page loads almost instantly

The ResourceHandler.ProcessRequest method does not appear to be called while ResourceHandler.Match is running slowly but is called just before/as the page is displayed .

I have a simple project that demonstrates this.

Tim

Hi Tim,

We have looked into the sample project you sent to us. The root of the problem is .NET ThreadPool thread creation throttling. The .NET thread pool will grow number of threads in the pool immediately as needed until it reaches a certain throttling threshold, after that threshold it will intentionally delay creation of new thread thus delaying the task submitted to the thread pool. This affects EO.WebBrowser custom resource handler since it uses thread pool to run both Match and Process.

To resolve the problem, call the following code once before you create any WebView:



The above code sets the "threshold" to 100. This does not mean the thread pool will pre-create 100 threads sitting there doing nothing. It only means as long as the total number of thread (concurrent tasks) in the thread pool is less than 100, if a new task is submitted and none of the existing thread is available, then a new thread will be created immediately. Once the total number of threads pass 100, the thread pool will introduce a delay on purpose. It was this delay that slows down the custom handler.

Hope this helps. Please feel free to let us know if there is anything else.

Thanks!

Hi,

Thanks for confirming the fix. We believe using thread pool is the best solution. There is no way to precisely control/ensure all "Match" to be called before all "Process" because your page can load resources dynamically anytime, and there is no way to predict total number of concurrent tasks either. Further more, both "Match" and "Process" are treated as independent thread pool tasks, so for the same resource, "Match" and "Process" can be called by different threads from the thread pool --- the only rule is "Process" has to be called after "Match" for a given resource. So blocking one "Match" call will not block "Process" for other resources.

The reason .NET has a threshold is to prevent the system creating an extremely high number of threads thus rapidly exhaust system resource. We could implement our our thread management to handle Match and Process and we would have to implement similar threshold mechanism to prevent a run away thread creation. So in the end you would have to settle with a reasonable total number of threads available either using the .NET built-in thread pool or not.

Hope that makes sense to you. If you have any other thought please share with us.

Thanks

Hi,

The tasks are short lived and the threads are indeed released to the thread pool. What you saw is a purely the delay .NET ThreadPool intentionally introduced while creating new thread. Let's say the ThreadPool only creates 1 thread without delay, the sequence of the event causing the delay would be like this:

1. Match A is submitted, a new thread X is created immediately to call this method. Say this method takes 5 milliseconds to complete;
2. Match B is submitted 2 milliseconds after step 1. At this point Match A is still not done yet since it takes 5 milliseconds. As a result, the thread pool concluded that it will need to create a new thread Y;
3. Since now the thread pool have already reached the threshold value (1), it will introduce a delay to create a new thread, let's say 1 second. So Match B will not be called until 1 second later;
4. A few milliseconds after step 2, Match A completes and now thread X becomes available. However at this point Match B is already assigned with thread Y (which will be created after a delay), so thread X now is returned to the thread pool to serve the next request. However Match B will still be delayed since it has already been associated to thread Y;

This logic does appear a little strange since step 4 the thread pool could have just reuse thread X to run Match A, but that's not what happened. However increasing the threshold will eliminate this problem. The consequence of increasing the threshold is that you will see a large number of managed thread. These thread must exist at one point in order to serve a high number of concurrent tasks (both Match and Process) at the same time. However whether they will be eventually destroyed, or whether it's a problem if they are not destroyed remain to be seen. If that turns out to be a problem, we will investigate further and may change our code to manage the threads ourselves instead of using .NET's built-in thread pool.

Thanks!

You are very welcome. That's exactly why we choose to use .NET's built-in thread pool. MS has done many optimizations on it's built-in thread pool. The new Task Parallel Library in .NET 4 is also based on the built-in thread pool. So it has been extensively used and tested. The only nuisance is this thread creation delay that MS put in on purpose. So we believe using the built-in thread pool with a higher threshold value is the best solution for now. We may change our code to increase the threshold automatically in our code so that it will be one less thing for our users to worry about.

In any case please be rest assured that we are always open to optimizations and improving the product whatever way we can. So please feel free to share with us if you see any other problems or have any other thoughts about the product. User feedbacks are very important to us. We can not make a good product alone.

Thanks!