I observed that web pages using a lot of JavaScript -- in my case FluentUI controls -- are performing well using iexplore.exe but when I open the same HTML page using a Windows.Forms.WebBrowser component. Performance is much worse.
How can I make WebBrowser as fast as IE?
Steps to reproduce:
Open my test file using IE11
Open dropdown
Dropdown list should appear in a approximately 1 second
Scroll up and down and see immediate reaction
Now open URL http://playground1337.net/dropdown.html in a Windows.Forms.WebBrowser. You can e.g. use this sample WebBrowser program or this one
Open dropdown
It takes about 2-3 seconds until dropdown list appears
Scroll up and down and see how sluggish it feels
This question sounds a lot like this one but the answer is not applicable/needed here. My sample file uses <meta http-equiv="x-ua-compatible" content="IE=edge" > to make the WebBrowser component use the latest rendering engine. The mentioned answer uses FEATURE_BROWSER_EMULATION which has no positive effect when using x-ua-compatible.
By visiting https://html5test.com/ you'll see that both IE11 and WebBrowser get 312 points. So it seems that indeed both are using the same rendering engine. But IE is still faster. Why?
Ideas I had but which I could not confirm:
IE is creating a subprocess using parameter prefetch:2. Is this some kind of optimization?
When scrolling up and down using IE, GPU usage raises by about 10%:
When using the above mentioned WebBrowser programs, GPU usage is very high (70-80%).
Is WebBrowser doing some extra work? Is IE doing some optimizations?
Maybe I can directly embed IE into my application using command line parameter -embedding? Unfortunately when using that parameter there is no visible window.
Related
I've "upgraded" to IE 11 for the browser inside a c# application using the webbrowser control.
When I load my web page into the IE 11 browser natively everything works properly on the map.
When I'm in the c# application everything loads without error except that I can not click on the map and drag it.
All of my map click events will also not fire.
I can use the arrow keys to move the map, and the wheel mouse also works.
I have noticed that when I use IE 11 natively, and use the developer tools with "Break on all exceptions", I get an error in ol3 when its checking if PointerEvent.HAS_BUTTONS is supported, saying Object doesn't support this action.
error is on line 44619 of ol-debug.js, using ol-3.4.0
Note: Yes, I've set the proper registry values for the browser_emulation for both the 32 bit and 64 bit keys for my application name, and the one for the vhost.exe version of the application.
UPDATE:
I should also note that if I use
map.on('click', function(e) {
//do stuff
});
there is nothing fired... However, if I use jquery and do
$(map.getViewport().on('click', function(e) {
//do stuff
});
... then my click events work....
I know this is a bit of a late post, but hopefully it might help others if they stumble across it.
I was in exactly the same boat: using a WebBrowser control with compatibility set to IE11 was causing OpenLayers 3 to ignore mouse button clicks when displaying 2D maps. I tried CefSharp 3, and sure enough it resolves the problem, but there are other reasons why that can't be used for me. After lots of trial and error, I stumbled across this as a workable solution:
<meta http-equiv="X-UA-Compatible" content="IE=11" />
<script>
if (navigator.appVersion.indexOf("MSIE 7.") !== -1)
{
delete window.PointerEvent;
window.navigator.msPointerEnabled = false;
}
</script>
This needs to be on the page before the inclusion of ol.js.
It's a crude test of whether the page is running in a WebBrowser control admittedly, but should suffice now that IE7 is no longer supported. The only real instance of "MSIE 7." in the user agent string will be from a default WebBrowser control.
I've not found any other OpenLayers problems as yet.
So, I decided to roll back to IE10. Everything works in both the native browser and in the WebBrowser control.
IE11 breaks too much stuff, and isn't worth the "upgrade" at this point in time.
I will be checking out CefSharp in the future, just not enough time to put into upcoming release.
I was in the same situation than you a few months ago. The non working mouse events, are just the first symptom. I strongly recommend you to use Chromium for that, because at the end, you are not using an IE11 (Webbrowser control is based on a IE9 kernel), and you just can influence "a bit" how it works, BUT: if you have a complex problem you have no way to really update your browser, to debug, etc.
Chromium works really fine and you can embed it completely in your solution, star it separately to debug or test, and it's based on a modern chrome.
To integrate it on a .net solution, you can use:
https://github.com/cefsharp/CefSharp
Regards
The problem is related to the legacy input model, which is enabled by default for WebBrowser Controls hosted by an application.
To get your OpenLayers3 application working you have to disable it in the registry. To do this you have to set FEATURE_NINPUT_LEGACYMODE to 0 for your application. If this key doesn't exist in your FeatureControl branch, you have to create it manually.
For more information about the legacy input model read this.
I had a lot of issues with ol3 / WebBrowser in winforms, like a lot of features not working well;
After I added this in the HTML header, it was perfect :
<head>
<meta http-equiv="X-UA-Compatible" content="IE=10,chrome=1" />
I know that there already is a question like this: Force IE9 into browser compatibility view
But since adding:
<meta http-equiv="X-UA-Compatible" content="IE=9">
to the the head section and reloading the page with ctrl+F5 didn't help there must be another way.
On my website is also a bxslider and according to this: bxslider not working in IE9 I replaced the elements (which had empty href attribute) with tags - still not effect. The images of the slider are displayed in full size one below the other. After activating compatibility mode the site works perfect.
I don't wanna rebuild my application from the scratch so what could I do to force the compatibility-view? Or is there at least a good free debugging tool for that? I downloaded the firefox addon IE Tab which has a debugbar but to use it you have to buy a premium version. I just don't know what is causing the error...
I found what was causing the error: Why does JavaScript only work after opening developer tools in IE once?
So frustrating and so simple. It was caused by the console.logs in the script. Without them it works like a charm.
If you use this code at the start of your JS (I use it in all my projects) https://gist.githubusercontent.com/elijahmanor/7884984/raw/console-monkey-patch.js it will override the console.log function so you avoid errors in IE but still get logging in modern browsers like chrome.
We have a thin client business app, and we are heading to use HTML5 on client side (first only for specific tasks, like some SVG drag'n'drop UI and Canvas image generating).
I know, I can't call a HTML5 page in an iframe on a non-HTML5 page in Internet Explorer, because it will displayed as non-HTML5 page, like its parent.
I tought i can call it to a new window, via javascript.
But it isn't work too.
In the base app there is an
open.window('HTML5.asp','_blank')
function, where the HTML5.asp uses SVG and Canvas. And yes, it's tested, it's works, when called from a HTML5 environment.
There are any solution or workaround to make it work?
Thank you guys!
UPDATE
Thank you for your help, finally i found the mistake.
I've tried to create a simplified code for you, but i couldn't reproduce the bug, so i went over our algorithm again, first block by block, then line by line.
We have a function dictonary, what should be the same in all systems, but it doesn't :)
And i've used a formatting function from there, and the HTML5 page has crased, due to it.
Thank you, again :)
That's quite a coincidence: I was just, by chance, reading about the Google Chrome Frame IE plugin that apparently allows you to use Webkit and the V8 JS engine in IE.
In the web page, we add the tag:
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
(Of course, Chrome Frame needs to be installed. If it's not, perhaps a redirection to an installer might be an option...)
As I said, I just happened to be reading about this a few minutes before I saw your question, so I don't know if this would be of any use to you (nor do I have experience using it).
Good luck!
I'm trying to debug an intermittent, possibly timing-related drawing problem with JavaScript in Internet Explorer (IE9 including in IE8 mode).
Using the Developer Tools, I'm stepping through the lines that create, style, and display elements, but the actual browser window remains unchanged (and shows the Windows "Not Responding" title text much of the time), so I can't see what happens when.
With Firefox and Firebug, I can see the main window update at each step. But regrettably this problem doesn't occur in FF, so I can't debug there.
I've web-searched and looked at the MS articles on using the Developer Tools, but I can't find any discussion about single-stepping through JavaScript and seeing the results of each step. Is something wrong on my system, or is this just not possible?
32-bit IE9 on 64-bit Windows 7, in case that's relevant.
If you are able to step through the javascript code but the browser is not refreshing and crashing your best bet to debug it might be to isolate the problem. Say you are doing five things on a certain piece of code. Reduce that to just one thing and gradually pile up different process on top.
Not sure if this is the answer you are looking, but I have run into similar problem with IE 9 before so if you provide some code snippet which can be replicated I could help you further.
Update
If you are running into intermittent issues with IE make sure to add a meta tag so that IE doesn't load quirks mode after encountering something on your code. Add the following tag. More information here
<meta http-equiv="X-UA-Compatible" content="IE=edge" >
We did an application using rails(2.3.4), ruby(1.8.2), MySQL, JavaScript, jQuery. This is handling minimum 6000 records. We showing those records detail in table. In the beginning Mozilla taking 2m to load the whole page. We did the cache, eager loading, indexes. Now Mozilla taking 25s to load the whole page. But IE-7 taking 1m30s to load the page.
We don't know why IE-7 taking too much of time.
Any one can help us to detect the running time in IE-7 and tell your guidelines to improve performance in IE-7.
Any add-on is available in IE7 to see the AJAX request time taken as like Firebug add on.
Use partial loading. Don't try to load the 6000 records at once, load them in smaller segments, when needed. Even 5 second loading is too long, not to mention the 25 seconds or 1m 30s.
Oh and yeah, IE 7's JS engine just sucks.
From Table Rendering - IE Blog:
When Internet Explorer encounters a table it measures all the content
of the table before rendering so that it knows what the widths of the
columns are to render the content correctly. On the other hand Firefox
uses a different algorithm in that it renders the table contents
progressively before it has all been passed.
You can improve performance by setting the CSS rule table-layout: fixed. The renderer will then calculate the layout based on the first row of the table.
IE7 is slow, there's no real way of getting around that basic fact.
I'm going to answer your second question (about debugging tools for IE7) because I don't think I can give any useful advice on your main point about actually speeding up IE7.
Any add-on is available in IE7 to see the AJAX request time taken as like Firebug add on.
The first thing to try is IE8 or IE9. These browsers have a Developer Tools window (accessible via F12, just like Firebug). It isn't as good as Firebug, but it does do quite a bit, and it is a useful debugging tool. It also has a feature which allows you to switch the browser into IE7-compatibility mode. The idea is that you can test IE7 from the relative comforts of IE8 or IE9.
The down side is that it isn't actually IE7. It's just a pretend ID7, and not a particularly good one at that. It may or may not replicate the speed issues you're having with IE7, and it certainly has known bugs and quirks of its own which don't appear either in a real IE7 or in IE8 in normal mode.
But all that said, it might be good enough for you to run some tests and get some answers.
A second suggestion might be to try Firebug Lite. This is a cut-down version of Firebug which runs as a bookmarklet in any browser (but generally IE). It doesn't have all the features of the full version of Firebug, because there's only so much you can do without writing a browser plug-in, but it does do a surprising amount. If nothing else, it does give you the console functions, which can be a life saver for debugging.
I hope that helps.