Hi,
Thanks for a great control. We were getting ready to purchase the full version (with source) this week, but I ran into a major performance issue today.
The steps to reproduce it are:
1) Build a SWF that allows you to move around a "Flex window" / sprite around the screen. (Using the mx:Panel element.)
I have attached a sample f_in_box.swf that can be used to demonstrate the performance problem.
2) Modify your Sample04_Translucency.cpp as follows:
- Pass 0,0,1600,1200 as the window size values to CreateWindowEx
- Remove the line that centers the window, namely: //pFlashProjectorWnd->CenterWindow();
- Remove call to FPCLoadMovieFromResource
- Instead, add call to FPC_LoadMovie(hwndFlashPlayerControl,0,_T("path\to\your\f_in_box.swf"));
3) Launch the example. Try to drag the "Flex window" around the screen. The dragging is very slow and jagged, because a great deal of CPU time is spent doing something else.
(I suspect handling erronous WM_PAINT messages, but I'm uncertain, since I don't have the source to f_in_box yet.)
As a result, the performance of the resulting SWF is unacceptable. It becomes difficult to type characters, move the window around, or do anything else.
At this point, I assumed that perhaps this was just a limitation of WS_EX_LAYERED.
However, Adobe AIR does not suffer from this performance limitation when running the same SWF. A win32 API trace utility revelaed a glaring difference:
When Adobe AIR calls CreateWindowEx(....), it does *not* use the WS_POPUP style. In fact, it uses:
WS_EX_LAYERED,
WS_OVERLAPPED
WS_CLIPCHILDREN
WS_SYSMENU
WS_THICKFRAME
WS_MINIMIZEBOX
WS_MAXIMIZEBOX
WS_GROUP
WS_TABSTOP
4) Interestingly enough, if you remove the WS_POPUP style from Sample04_Translucency.cpp, everything works fine! The performance is great (even better than Adobe AIR), and the window can be dragged
around, text typed quickly, etc.
However, when I remove WS_POPUP from Sample04_Translucency.cpp, I run into another problem. The painting of the hWnd hosting the flash control gets messed up very quickly. In the sample I've provided, try typing text into the lower text field. You'll notice that the damaged areas of the win32 window fail to repaint themselves.
My guess is, as soon as damaged regions of the window arrive, the window fails to repaint it with content from the sWF.
Here's my question:
How can we get the performance that currently occurs without WS_POPUP, and yet have correct painting behavior?
If this problem is resolved, I can get my manager to buy a full (with source) license (or perhaps even a site license for future devs maintaining our app).
Alternately, feel free to email me a copy of the source, and I can try to find a fix, and send you guys a copy if I'm able to create a fix.
Additionally, I speak and read Russian fluently, so if it's easier to respond in Russian, please feel free to do so. (I just can't write very well -- it would be embarrassing if I tried.)
Also, please advise of a timeline as to when this issue can be resolved, so that I can give my manager an update.
Thanks for all your help!
denster201 [remove-thisthing-]-at-yahoo.com