This is an HTML 5 Canvas application. It's a pretty standard "designer" application where the user adds objects to a layout, moves them around, and edits their properties.
It works very well, but it turns out to have real performance problems in IE 9 on Windows 7. I would appreciate any thoughts!
Operations often take 10 seconds instead of the usual 2 seconds.
Also, after using the application a little while, the browser gives an error message that the host "is not responding", giving options Recover Webpage and X. Once that starts to happen, it happens for every user action including the File menu, and I can only get out of it by editing the URL location text. In particular, it generally happens on any attempt to use the browser's profiler in Developer Tools. This is obviously frustrating, but it may also be a clue. I wondered if there might be pending synchronous AJAX calls, as suggested by this error message, but capturing the network traffic using Developer Tools suggests that all calls are complete.
The problem seems specific to this combination of browser and OS. IE 9 on Windows Server 2008 behaves OK, and so do Firefox and Chrome on Windows 7. The problem is the same for 32-bit or 64-bit IE.
Most of these operations have a server-side component too. For example, adding a text object makes an AJAX call to serve an image for the object. The server API is implemented as a small TurboGears application which uses ImageMagick for the image processing. But rough profiling indicates that nothing unusual is happening on the server side. This suggests that the problem really is in the JavaScript.
The Task Manager shows the browser using CPU of 90% or more when the application is running. This is true for any browser, not just IE 9. This is likely because of the tight rendering loop in the application, so one idea we had was to redraw the canvas less often. Unfortunately this did not seem to help. requestAnimationFrame seems like a good idea, but is not supported in IE 9.
A colleague suggested that using the Google Chrome Frame plug-in might help. It might be an acceptable solution, but I haven't tried it yet.
I found some advice to turn on the Control Panel option "Use software rendering instead of GPU rendering", but that doesn't seem to help.
One thing I have noticed: It seems the canvas is much slower in IE if you start drawing on it when it's not in the document.
So I do document.body.appendChild(canvasEl) before I draw. You can even make the canvas element dislay: none; but at least it should be in the body.
Update: It seems that for Chrome and Firefox, appending the canvas to the body is slower. So if you don't need it to be added to the body, don't add it for Chrome and Firefox.
Related
Recently a Chrome extension our company uses was reported to be causing extreme slow down in the UI when in use. Ive been trying to find the cause of this issue.
After a week or two I have narrowed it down to the canvas's drawImage method.
Initial thought was that this method was holding onto the thread for too long.
This extension works great up to Chrome V43 (couldn't find chrome V44 anyway). With the current version 45, it causes heavy delay on UI response. Seems like a chrome bug.
Googling around I found this https://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=&id=490478
I am not sure if this is exactly the issue I am running into with drawImage but taking the suggestion from someone who posted there, I went into chrome://flags/ and disabled "Disable accelerated 2D canvas".
This instantly solved the issue & the extension is actually working better than ever before. The question is why? and how can this be used to make a temporary fix to the code since it'd be unreasonable to just ask everyone to disable this flag.
Two and a half years ago Adobe announced that FlashPlayer 10 would support color correction. Admittedly the implementation was really basic because it would always assume all content to be sRGB encoded and would convert that content to the current display profile in use on the system. This was the introduction blog post by John Nack.
All AS3 needed to activate this feature is:
stage.colorCorrection = ColorCorrection.ON;
...and yes you do need stage access for this to work and no that is not the problem.
So back when it was new I wrote a little wrapper to display images in Internet Explorer and Chrome so that they would render correctly for folks with extended gamut displays and also used this in a flash based video player with the same purpose.
Revisiting either today I find that what I know to have worked no longer does. What changed in the meantime is FlashPlayer's version and most likely the browser versions, too. I tried OS X, Win 7, Win XP, icc v2 and icc v4 display profiles on all of these, different browser versions, flash player versions to no avail.
You'll say that I must have done something wrong but the example page Adobe published a while later and which I lknow to have worked for sure also fails nowadays. If you look at the Flash applet you'll find it saying:
stage.colorCorrectionSupport: unsupported
If it sais supported for your system please comment the OS, browser and version and FlashPlayer version. Otherwise I'm looking for any clues to what happened to this feature.
At least the Adobe staff participating on their boards seems to be clueless. Quote: Because this feature seems to be disabled by default in most major browsers, I'm thinking that it was an experimental web standard proposal that died or something. We're not doing a whole lot here, it's mostly dependent on the browsers passing us the right data and doing the right color conversion math. We're pretty far down the chain of events.
I know for a fact that this worked at some point of FlashPlayer's evolution. So the following might help in solving what's going on:
does the Adobe example still work for anyone caring to look?
if this were about a deprecated browser feature why doesn't it work on old browsers anymore?
did it stop working on any particular FlashPlayer? (I tried several but could no longer make it work)
Notes:
color correction did not work with wmode transparent for some reason (but opaque was fine)
color correction originally also sometimes failed when using alpha bleding transitions
UPDATE: The feature still seems to work when wmode is set to "window". Of course that is very limiting. If you have a lightbox etc. on a page the Flash content will always stay on top of it etc. - so that's bad.
With wmode="window" the example also worked for me on OSX 10.6 (only version I tested thus far) and Win XP 32 bit. It still failed with all win 64 bit versions I tried but those systems have multiple screens so maybe I'll have to retry with a single screen since the first comment below suggests it worked on Win 7 64.
On the systems this worked I tried Firefox, Safari, Internet Explorer and Chrome. All worked the same except that when using Chrome the built-in Flash player always gives stage.colorCorrectionSupport: unsupported while disabeling the built-in FP and using the system's Flash player works as in the other browsers.
So the questions above can be narrowed to why does this no longer work for any other wmode especially "opaque" - which did work before and which is what Adobe uses in their on-line version of the sample file...
UPDATE 2: Flash Player's newer wmodes "gpu" and "direct" make the feature fail on the systems / browsers named above where wmode "window" worked out.
UPDATE 3: After finding the wmode = "window" angle I decided to post a follow-up on the Adobe forum I quoted from initially. That lead to this whole issue being acknowledged as a bug in Flash player at: https://bugbase.adobe.com/index.cfm?event=bug&id=3596843 So I guess there won't be an answer to the question of what happened to stage.colorCorrection but hopefully it will sort itself out.
UPDATE 4: O.k. here is the mandatory bit of stupidity... When I said that I remembered wmode "opaque" to have worked before I errored. Upon reviewing this further I found that a long time ago I had put wmode="normal" in one of my JS files and since normal does not exist older versions of Flash Player used the standard wmode window so that was why it worked back then. More modern Flash Players have other defaults e.g. direct where color management fails and so it failed for me. So I think this never worked with any wmode other than "window" but I'm curious what the future might bring for this...
(yeah this is an old question, but I was product manager for Flash Player 10, so I thought I'd answer)
It works with window mode because Flash Player gets the rectangle in the browser and gets pretty much full control of the rendering stack and doesn't have to deal with compositing with items it doesn't know the color status of.
When you switch to something like wmode transparent, you go into a pretty crazy back and forth process compositing with the rendered elements above and below it. When you go into wmode GPU, the rendering stack is largely handed over to the GPU (not surprisingly). In both cases, Flash Player loses some control of the rendering stack and at that point things like color correction aren't possible.
The primary reason for this feature in Flash Player 10 was to enable interactive e-publishing in Flash Player (like inDesign SWF export) as well as support for applications that could help in a print-oriented tool chain.
Just updated Chrome to 18.0.1025.142 from 17 on a Mac running 10.7.1 and it's killed the performance of our site. We've been using translate3d where available to move a large number of items around the screen. I'm animating with requestAnimationFrame. In 17 we were getting framerates upwards of 50fps. Now lucky to get 15fps. It's really bad.
Has hardware acceleration been turned off by default? Anyone else noticed any problems like this? I've noticed the font rendering has been improved and is now on a par with Safari (which runs the site beautifully) maybe this change has had an effect on general rendering performance?
I'm afraid I can't share the link due to an NDA. But any help would be greatly appreciated!
Update:
As far as I can tell it IS still GPU accelerated but the performance is really bad, other people have reported similar things. The Chromium builds of v19 seem to be back to the old quality of performance.
There used to be a flag when launching chrome --show-composited-layer-borders which would put red borders around gpu accelerated elements. This option now seems to have been added to chrome://flags/ but it paints green borders around layers and doesn't seem to distinguish gpu elements any more. Does anyone know of an option to show if elements are being rendered by the gpu?
chrome://gpu/ says that everything is being hardware accelerated...
Reproduce the problem with fresh code in a new web page. This will greatly help both your SO question and bug report.
Browsers regularly tweak whether hardware acceleration is used based on whether your graphics card and driver version is supported. Updating your graphics card driver may fix the problem for you, but maybe not everyone else. (This tool I wrote might help: graphics driver updater)
In fact it's a bad idea for your website to depend on hardware acceleration, because a significant fraction of users have crappy unsupported hardware and/or out of date drivers which are blacklisted to stop the user's computer crashing while they browse the web. They'll get crappy, un-accelerated framerates too, in any version of Chrome.
So IMO the real problem is your website depends on hardware acceleration which not everyone has, and you just noticed because Google blacklisted your setup in Chrome 18.
We're looking for a tool that would allow us to script and run tests across multiple browsers including Chrome, FF 3,4, IE 6,7,8 and during the running allow a human to visually inspect each page / action. This must support javascript so a simple browsershots approach will not work. Something like Selenium Grid may work but I haven't seen anything that would act like a console so that a human could visually inspect each test step. Ideally the answer to this question would be a tool that runs a scripted front-end test and displays those tests on each browser in a grid so that a human could visually inspect the look of each page while the test was testing the html content.
How about Cucumber Sauce?
I've not tried it purely because I do not need to run tests in parallel across multiple browsers or headless. However, I am using Cucumber BDD for almost all my web application testing. Cucumber Sauce looks like it might have solved the parallelism problem so it might work for you.
How about Telerik Test Studio http://www.telerik.com/automated-testing-tools.aspx? It can do FF 3 & 4, IE7, 8, 9 (but not IE6), Chrome and Safari. It literally hooks into the browser and drives it as if a real person was sitting there clicking things and typing text.
A couple months ago I ran into a browser that allowed users to see how different rendering engines displayed their site: Lunascape, and here are its features. As far as it validity, or accuracy goes, I cannot vouch for it (I have never used it); I can link you to a CNET review though: CNET.
So my best idea would be to use lunascape (to allow your tester to see all the engines side-by-side), then script the tests in javascript which is included in every page.
Good luck, and hope this helps.
TestComplete can do this: http://www.automatedqa.com/products/testcomplete/
You can record any interaction with an application and when the tests run you can watch them.
It supports:
Internet Explorer 6—9 support (both 32- and 64-bit versions)
Firefox 3.5—4.0 support
Open source tool Selenium, which supports many browsers and can be run as a simple record / playback tool or from code but the browser compatibility varies a bit depending on which method you choose. Google uses Selenium in a big way these days and there are plenty of good articles such as this one on their testing blog.
Very good question.
The closet tool that i think of will be HP load runner for :
the ability to visually inspect each page while the test is running and inserting break point if needed
Javascript is supported but you might have problem with asynchronous request (ajax)
Since there is alway a but :
Not all browsers are simulated.
Browsers are simulated also ...
The report will print the performance and not what was shown on the page.
The price
I do not think that visual inspection falls into automated test. Automated test is about performance and to detect regression. Visual inspection on the other side is to check if the layout is properly rendered.
Doesn't this testing depend on the size of the site to be tested? If I have a 5-10 page site, I would use some of the tools mentioned above, handle it manually (i.e. walk through the site in each browser on each platform), use browsershots.org, or use a tool within Safari, such as simulating a browser.
If the site is large, then these options become very difficult and time consuming, and my experience is that the best thing to do is make sure that each page is standards compliant, and try different pages in a few browsers.
Hope this helps.
when I running one asp.net web site, there is one page is running very slow in IE, but other pages are running ok. It' wired that this page is running ok in firefox. Is there someone know the problem is? thanks!!! I am using Asp.net and js on that page
Is the page JavaScript intensive? JS in IE is notably slower.
In addition to Andy Gaskell answer. IE only can get 2 resources at a time (images, css, js, whatever) , while FF gets 4. So, for the same given page Firefox will be able to download it faster than IE (granted that there is enough bandwidth)
Also, Firefox supports http pipelining wich accelerate things even more if the server supports http 1.1. It's disabled by default because supposedly it can have problems with some old servers, But the truth is I'm using it since Firefox 0.4 and never had an issue.