|
|
Rank: Advanced Member
Groups: Member
Joined: 4/17/2014
Posts: 35
|
Hi
We are loading offline web pages to the EO.WebBrowser which are animated / modified by Javascript. (mostly the page stays same, but DOM is heavily modified)
Recently i was testing other systems, such as android (etc...) and noticed that theirs web component is performing much faster.
So that gave me an idea, that maybe I'm not optimizing EO browser component fully.
Can you suggest ways to increase the js performance?
We are using mostly over average powerful computers, so i would still like to see that these computers perform better than a phone.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi, There are no options/properties to speed up JavaScript. Chrome has a rather fast JavaScript engine, however it is very possible that the page tries to automatically detect different type of device and then acts differently. So you might want to try to load the same page in a regular browser on desktop and see if see any significant difference. If there is no significant difference between a regular browser and EO.WebBrowser, then the problem is probably in your page. On the other hand if it does run fine in a regular browser but significantly slower in EO.WebBrowser, then you can try to isolate the problem to a test project and send us the test project. See here for guidelines for the test project: http://www.essentialobjects.com/forum/test_project.aspxThanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 4/17/2014
Posts: 35
|
Hmm, seems that I'm losing more performance when communicating with between C# and JS, otherwise it seems fine.
Can you comment a bit the link (C# <=> JS) speed / performance?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Yes. This makes sense. While JavaScript <=> C# is a great feature, it does come with significant performance cost. This is because the JavaScript runs inside the browser's render process (this is a separate process that runs HTML layout, rendering and JavaScript) and your C# runs inside your own process. As a result, every call between the two must be marshaled between these two processes. This compares with a direct JavaScript call (which Chrome would compile to native code) and the difference would be significant. You can try to optimize the number of calls by using EvalScript. For example, the following code causes three round trips between C# and JavaScript:
Code: C#
EO.WebBrowser.DOM.Element body = WebView1.GetDOMWindow().document.body;
The first round trip is GetDOMWindow. The second is to get document, the third is to get body. However the following code only makes a single round trip between C# and JavaScript:
Code: C#
EO.WebBrowser.DOM.Element body = WebView1.EvalScript("document.body") as EO.WebBrowser.DOM.Element;
You can try this and see if it can improve the performance for you. The key is to reduce the costly C# <=> JavaScript marshaling. Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 4/17/2014
Posts: 35
|
Thanks for the great response!
I'm already using EvalScript feature, but instead of one call i had a few of these in performance critical place.
I managed to reduce call's by creating js objects and passing json string to C# side. So i could easily convert string to C# object with Json.NET library.
Seems that heavy 3rd party library's are also affecting C# <=> JS performance.
For example, if I'm running app with Kinect For Windows it slows communication a lot (but CPU is not maxed out).
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Rasmus wrote:Seems that heavy 3rd party library's are also affecting C# <=> JS performance.
For example, if I'm running app with Kinect For Windows it slows communication a lot (but CPU is not maxed out). This is possible if they "eat up" the UI thread. In the current implementation, all the C# <=> JS marshaling not only has to go between two different processes, but also when it reaches your own process, it has to go through the UI thread's message queue. This means that if your UI thread is always busy, it will greatly affect the performance. It is implemented this way so that you do not have to worry about thread synchronization issues yourself. We might introduce more advanced options to allow you to handle/serving such calls in a dedicated working thread and that maybe able to improve the performance a bit. Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 4/17/2014
Posts: 35
|
Thanks!
I have now much more clear idea whats going on there.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
You are very welcome. Please feel free to let us know if there is anything else.
|
|