I was playing with new Silverlight 4 and to my surprise when I run my sample application in OOB all animations become very jerky when I moved mouse around during animations, but when I run my app in browser animations are smooth even when moving mouse around.
I tried my app on two different computers, turned on GPU acceleration in OOB settings - and got the same jerky result.
Is this a know problem with Silverlight?
I'm running WinXP SP3
UPDATE: Tested on 3 Windows 7 machines - no issues at all (running in OOB and in browser), tested additional 5 WinXP SP3 machines - 100% reproducible problem on any Silverlight 4 app running in OOB
Turning on "Enable GPU acceleration in Out of Browser" isn't enough. That setting works in tandem with .CacheMode property, which must be set on all elements (or a top-level element) whose rendered bitmap will be sent to the GPU.
From there, the GPU can hardware accelerate rotations, scalings, opacities, clipping. If your animation does any of that, you'll need to set element.CacheMode = "BitmapCache" on the top level element you are animating.
Again, you'll need to turn on the "enable GPU acceleration" for this to work.
If either step is missing, you won't get GPU accelerated.
A couple of caveats for hardware acceleration:
Pixel shaders and perspective transforms are not HW accelerated last I checked.
HW acceleration works on XP, but requires that you have a video card from NVidia, ATI, or Intel, and the driver date must be post Nov 2004. Anything less and nothing will be accelerated.
I recommend reading MSDN's article on hardware acceleration.
Related
I have a problem with OBS. I'd like to make tutorials how to do programming, teach people basics & show them, for example, how to write neural network in Java (without any ML libraries) but in order to do so, it would be great to show them my presentation about it and other windows, so recording full screen is needed (I know I could keep switching windows but it's faster and easier to display full screen). When I added the source "capture screen" the captured screen is black but audio works. I've tried to solve this problem and I went through many tutorials (like 15 or smth) and nothing has helped. I've also added a new thread in OBS Official Forum but nobody has responded. My OBS version is 25.0.4. Here is what I've tried:
- I ran the program as an administrator
- I have reinstalled it (with deleting all files and settings ~ no leftovers)
- In Nvidia Control Panel in 3D Settings I've selected OBS Studio and changed graphic processor to an integrated graphic (also tried dedicated graphic and global choice - nothing worked)
- In GForce Experience I disabled sharing
- Couple times I've restarted the computer and OBS (after any change I've done)
- I ran the OBS in compatibility mode with Windows 8 (and I've tried Windows build-in troubleshooting option)
- I ran OBS with an integrated graphic from a desktop
What I've discovered is the capturing specific window works perfectly, the problem occurs only with capturing full screen.
I have no idea what to do, please help me.
Here is what I see:
It looks like OBS just "can't see" screen, I use only one screen by the way
Black screen
though single-window capturing works perfectly
5
OBS Settings vol.1
OBS Settings vol.2
Logs:
https://obsproject.com/logs/NMexpZp-b4nXDxLl
Specifications of my computer:
I use a laptop - MSI GF 63 8RC
- Intell Core i5 8300H
- GForce GTX 1050 (actualizations are installed) 4GB VRAM
- Windows 10 Home, 64bit (updated to version 1909)
- 16GB RAM
- FHD Screen (1920x1080)
You will need to change the Graphic for this app to integrated graphic
I had the same problem in the virtual machine And I solved it this way go to virtual machine setting
in display section uncheck Accelerate 3D graphics
The problem was solved and the recording was done correctly.
When I run my Windows 8.1 app inside Windows 10 preview (build 10240 and also all prior versions) all controls are quite tiny.
Normally the screen has 1366x768 physical pixels (and a scaling factor of 1.0 was reported).
When running the Windows 8.1 app inside Windows 10, a logical resolution of 1645.783... x 925.301... is reported (and still a scaling factor of 1.0 is reported).
Windows 10 then seems to downscale the 1645.783... x 925.301 "pixels" to the 1366x768 physical pixels which leads in notably smaller controls (while more content is shown)
The "magic factor" is 1.2048... which is exactly 1.0 / 0.83.
I know that Windows 10 has new scaling plateus. But this all does not make sense at all. The artificial scaling has an akward factor. Actually, leaving 1366x768 (#1.0) would be perfect. I consider this as a serious bug.
What is Windows 10 doing?
(I could port my Win 8.1 app to Win 10 so that the scaling would be OK again, but I would like to wait some months till the tools are really ready)
In Windows 10 display scaling affects both desktop apps and Windows apps. In Windows 8 however, display scaling only affected desktop apps. Your issue might be linked to this. Check your display scaling in Settings > System > Display > "Change the size of text, apps and other items".
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.
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'm doing a phone app with some animations and they look really clunky on the emulator. I don't have a phone yet so this is the only way I can test my app.
Sometimes the animations start late (up to a second after user input) and the they are almost always very jagged. Far from the smooth fades and transitions that I've seen on the interwebs. I'm not using anything hairy - just basic rotations and opacity fades on one or two elements.
Does anyone else see this in the emulator? If not, i guess I have a bug somewhere. If so, is there a work around? Should I bump the priority of the xde.exe in process explorer? Other?
Thanks!
This may be a consequence of gpu detection no working on your system.
You can verify this by checking if you can see the frame rate counters.
Jeff Wilcox – Frame rate counters in Windows Phone
Note the emulator system requirements here also.
Setup and System Requirements for Windows Phone Emulator