[Solved] differences between using wmode=”transparent”, “opaque”, or “window” for an embedded object on a webpage
when embedding a Flash object with the
<embed> tag, there is an attribute called
wmode. It seems that most of the time,
wmode="transparent" is the same as
wmode="opaque" as the Flash doesn’t actually have any transparent color so that the bottom HTML element is to be shown. As a result,
opaque should be faster than
transparent since it requires less processing for transparency, yet most of the time i see Flash object embedded with
transparent instead of
opaque is needed so that other HTML element won’t be covered up by the Flash object (such as a menu item that pops up an extra sub-menu won’t be covered up by the Flash object).
By the way, is there formal documentation for
window? I was only able to find blogs that describe it but not the formal documentation. thanks.
Here is some weak adobe documentation on different flash 9 wmode settings.
A note of caution on wmode transparent is here in the adobe bug trac.
And new for flash 10, are two new wmodes: gpu and direct. Please refer to Adobe Knowledge Base about wmode.
Opaque will cause less system strain since ‘transparent’ will still attempt to apply alpha. The reason you see transparent used instead is because most web authors don’t pay attention to detail (ie, just copy-pasted some embed code they found).
BTW, you are correct about it being undocumented. The best I’ve ever seen is a blog by a guy who claims to have talked to a Macromedia developer about it. Unfortunaetly I can’t find the link.
EDIT: I think it was this one: http://www.communitymx.com/content/article.cfm?cid=e5141
wmode=opaque and with IE, the Flash gets the keyboard events, but also the html page receives them, so it can’t be use for something like embedding a flash game. Very annoying
There’s a pretty good write up in the Adobe KB’s on ‘wmode’ and other attributes with regards to their effect on presentation and performance.
One bizarre thing is that in Chrome + Firefox, the MOUSE_LEAVE event isn’t dispatched for
WINDOW it works fine. That one took some time to find out! grr…
(note: jediericb mentioned this bug – which is similar but doesn’t mention