I have created a Flash game which plays at 60 frames per second. It plays fine in all browsers except Internet Explorer 8 and 9; in these cases, it seems to be half (or less than half) the intended frame rate.
I have tried embedding it even by using Flash Authoring Tool's own html code, as well as the swfobject method, but to no avail. In all cases, GPU acceleration is enabled.
It's also not a matter of CPU performance, since it is tested on the same computer with all other applications closed. The problem only rises with IE.
One final peculiarity to consider : I have loaded FRAPS to count the actual rendering frame rate and it shows it to be 60 fps (inside IE), although it's crystal clear that this is not the actual speed achieved.
sounds like flash isn't properly installed on your IE browser
Try the following (assuming you have Adobe Flash Player v10.2 installed):
• Restart your computer.
• Open Internet Options (located in the Control Panel).
• Click on the Advanced tab.
• Click on the Reset button, place a check next to Delete Personal Settings and then click Reset.
• Launch IE9 and Adobe Flash Player will be properly enabled.
then try your tests again
GPU acceleration is not always the best solution. It depends on the way you have code the app.
Try another wmode value.
Related
I've built a small game that running perfectly while on local (from Flash). It's a small 60-fps game. Using the same computer, I'm playing the swf using a browser (Chrome, Firefox, Explorer) however it's running extremely slow. I'm using swf monitor (and Browser monitor) there you can see clearly the swf is running with 61/60 fps however this is just not true. Seem like the browser is forcing swf fps down to around the 20 fps or so. I've also tried Wmode (direct / GPU) but nothing. What is going on?
After updating my graphic card drivers, everything works perfectly even on Browser. Flash can handle it perfectly without updated drivers, but on a browser it's a must to have, else it will damage application performance and FPS.
I have been testing the Apple CoreMediaIO sample camera on Mac OS X 10.9 Mavericks.
Locally the applications i have tried could detect and recognize the sample camera automatically (like Skype, AVRecorder - Apple's AVFoundation capture API sample)
In Mozilla Firefox and Opera browsers the camera has been detected automatically on the Flash Player based sites that i have checked (for example Adobe's Cirrus sample), although in Safari and Chrome the sample camera was missing from the video input devices list.
How could i make these browsers recognize the CoreMediaIO sample camera on such a website?
Safari:
The problem causing this to happen is that on Mavericks the current Safari uses a sandboxed Flash Player which refuses to detect the sample camera.
You can solve this by allowing sites to run Flash Player in unsafe mode: (make sure you have allowed the website to use your cameras on the Flash Player pop-up window)
Go to Safari/Preferences.
Go to the Security page.
Click Manage Website Settings.
On the left pane select Adobe Flash Player.
Select the website you have allowed to use the camera and want to use the camera with.
Click on the combobox.
Select Run in Unsafe Mode.
On the pop-up window choose Trust.
Refresh the website.
From now on, Safari can detect the sample camera on the specific website.
I could not find a better/all-around solution yet.
Chrome:
This problem is mainly based on the Mac OS X AVFoundation API being disabled by default in the current Chrome (the CoreMediaIO sample uses it).
There are various methods to make Chrome detect the sample camera.
So far my best solution is the following:
Open a new tab in chrome.
Go to chrome://flags.
Search for "Enable use of Mac OS X AVFoundation APIs, instead of QTKit, Mac" entry.
Set the above-mentioned entry to Enabled.
Relaunch Chrome.
As far as i could get, the key AVFoundation flag's internal ID is IDS_FLAGS_DISABLE_AVFOUNDATION_NAME.
As long as you try to use AVFoundation based things in Chrome (OS X Mavericks) you will probably need this. (I don't really know why the default value is disabled, but i hope they will change it as Apple tends to deprecate QTKit.)
Other solutions that i prefer less:
Disabling Pepper Flash (PPAPI) and using NPAPI Flash Player instead.
Open a new tab in chrome.
Go to chrome://plugins.
Hit the plus (+) sign in the upper right corner next to Details.
Search for the Adobe Flash Player plugin section.
Locate the Pepper Flash version (PPAPI type).
Click Disable.
Refresh the website.
Google intends to deprecate NPAPI Flash Player soon, which leaves the Pepper Flash (PPAPI) as the only alternative, that was the reason to try and find a better solution than this. I don't recommend to rely on this solution considering the future of NPAPI Flash Player.
There is another temporary solution involving Mozilla Firefox. I don't know why exactly this works and i think this might easily change in the future, but i tried and verified that it works at the moment:
Close Chrome entirely (Chrome/Quit Google Chrome or Command+Q).
Start Firefox.
Go to the website you would like to use the camera with (any Flash Player based site works that calls for camera list).
Open Chrome.
Close Firefox.
Go to the website in Chrome.
If you close Chrome you will have to redo the process from Step #2. It seems like Firefox initializes something that makes the Chrome startup different and causes it to detect the sample camera. I don't recommend to rely on this though.
I'm experiencing issues with the YouTube player failing to load when the power save mode is enabled in Safari 6.1 and 7 on OSX. The issue doesn't happen if the youtube user is using the experimental HTML5 player, but it's still in beta and most people are still using the Flash player. The "disable plugins to save power" option is on by default in most new versions of Safari and this causes the YouTube iFrame API to enter an endless loop as it tries to initialize the player.
Is there any attribute on the window or navigator objects that would possibly indicate that the power save mode is enabled so that I can warn users?
This issue is semi-intentional. The Power Saver mode in Safari deliberately stops flash content. You can read more about it in this article.
If the flash content is 'front and centre' (within a 3000 x 3000 pixel boundary starting at the top left corner of the document) it should still play. So it may help, if the youtube video is off to the side of the page, to try and centre it. Apple says content will not play if it is in the margins (see this page under the Safari Power Saver heading).
Well i do not think there is any readable JS property to know that,
if so Apple would have a flawed design, and the Safari Users would get nagged to disable that mode, in order to have the web site working "properly" ...
What you could do of course is to try to make a server call on your web site via flash, and then try to read the changed session variable via JavaScript, then you would know ...
I am in the process of porting a Flash Player-based game over to the Desktop (OSX and Windows) via Adobe AIR (3.1). The porting to AIR itself has gone rather smoothly. The one wrinkle I've been dealt is that the game will be distributed over the Steam network. In order to interact with the Steam Client, I've had to write a native extension to expose the Steam SDK APIs to AS3. The native extension support has been implemented for both platforms, and I have the application launching and communicating with Steam as desired.
The area I've run into trouble is dealing with Steam's Overlay, which renders overtop of games when it is activated. Essentially, when a game is launched, the Steam Client suspends the process in order to hook its Overlay library up to either D3D or OpenGL. Initially, the Overlay failed to appear at all as the AIR application descriptor had the default rendermode set to "auto." However, once I switched the rendermode to "gpu" the Overlay would appear as desired.
On the OSX side of things, everything works as expected. I can toggle in and out of the Overlay just fine. On the windows end of the spectrum, I've hit a bit of a problem when I activate the Overlay. Specifically, when the Overlay is enabled (it's rendering overtop of the game) and I either move the mouse or generate keyboard input, both the Overlay and the game both "freeze" (rendering stops) for 2-3 seconds. Additionally, I have noticed that when I open the Task Manager with the game running, the cpu usage is roughly 75-80%. The cpu usage remains the same when I first active the Overlay (which is desired). However, when I move the mouse cursor or press a key on the keyboard, the cpu usage drops to roughly 1%. This problem has occurred on 4 of 5 windows machines (2 XP, 3 Win 7) we've tested on. Naturally, I first contacted Valve about the issue since this only occurs when the Overlay is enabled. I've uploaded both the OSX and Windows builds for their devs to debug; however, my contact suggested I find out more about AIRs rendering/input as well.
Here is a snippet of a post with a Steam Dev detailing how the overlay works:
"The requirements for the overlay on Windows are as follows:
Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
Game must call D3D Present() or OpenGL SwapBuffers() on a fast regular basis (these calls are hooked by the overlay and give it opportunity to do work). For instance 2D games that only call these functions when mouse movement occurs or graphics on screen actually change rather than every frame will not function well.
Game should use standard Win32 input messages, raw Win32 input messages, or DirectInput for input and the overlay will then detect hotkeys and hide/block input events from the game when active.
It sounds like your game may violate #2 and stops calling Present/SwapBuffers sometimes when the overlay is active. This may happen if you call these functions in response to user input which is now blocked due to the overlay being activated. You should guarantee you keep pumping frames and swapping at a regular interval even if input events aren't occurring."
After a little more prodding, the Valve devs profiled my application to determine if there was any specific problem occuring with the Game Overlay. Unfortunately, they were unable to find anything going on in the Overlay itself. This pretty much means that AIR on Windows doesn't like that the Overlay is blocking Win32 input messages. Here is the Valve dev's response:
"I got your depots and did some testing. Nothing unusual happens in the overlay. Profiling your app with xpref while the issue occurs and taking some minidumps to check callstacks it looks like the app just blocks up completely and uses zero CPU during the time it is blocked, when it happens it calls Present() only at roughly 1 second intervals until it recovers (maybe there is a 1 second timeout somewhere in the AIR code). It's hard to get much detail since I don't have any symbols for the AIR runtime libraries.
It does however look like this is somehow related to input state and AIR being unhappy with win32 input messages stopping. If I change our overlay to not block any input at all once activated (which obviously has some pretty big problems for usability, but just for testing purposes.) then the issue does not occur. It's possible that the AIR code has some weird logic where if it's seen some specific WM_WHATVER message it's expecting another right after and blocks on it waiting somehow.
Hopefully you can work out on your side or with Adobe as to why the application behaves badly in these situations and starts blocking and not presenting at regular intervals."
I've posted on the Adobe forums, but haven't had any such luck over there. Mainly, I'm hoping that someone has either dealt with this before or has an idea about how I could possibly get around the issue. Any suggestions, comments or thoughts would be greatly appreciated!
As it turns out, there is an bug deep in AIR core framework that is the root cause of this issue. Adobe has confirmed the bug, and they are working on a fix for the Cyril (AIR 3.3) release. The status of the bug (#3089755) can be viewed in the Adobe AIR bug list.
In the short-term, I was forced to detect Windows messages that were being consumed by the SteamOverlay, and pass on fake messages to prevent AIR from locking up. I accomplished this by using the Windows API SetWindowsHookEx along with the WH_DEBUG and WH_GETMESSAGE hooks. This is definitely not a desirable approach, but was needed in the short-term until Adobe releases a fix.
I know virtually nothing about Flash so I'm kind of casting about in the dark.
I have the misfortune of being a BT customer, and whilst I have reasonable bandwidth (can view streaming high res video fine) I always have problems listening to radio programmes from the BBC. I think it could be buffering due to traffic shaping, or it could be the Flash applet used to play the content, or something else.
Is it possible to bring up some kind of debugging console, or view some kind of error log to see if there is some diagnostic information that could be useful in finding the problem?
Chrome/Firefox/Safari using Adobe Flash player 10.2.159 on Mac OS X 10.6
EDIT: In the debug Flash player the 'debug' option is greyed out, suggesting that the swf was compiled without debug symbols. This was created by a third party (BBC) not me.
You could install the debug Flash Player, so you should see if an error occurs (a popup will appear on the screen) during the streaming.flash player debugger download
You should also disable flash player plugin and turn on debugger. If you're using Chrome type chrome://plugins the disable flash player and enable Adobe Shockwave for Director Netscape plug-in.