I have a very weird bug that I just can't understand.
I am currently using the WPFMediaKit library in one of my programs.
When using the library in a near empty new "demo" wpf solution, the image from the USB Camera source is rendered perfectly to the MediaCaptureElement class.
However, using a more complex solution, the same library (without changes), the frame gets rendered black. I can see there is connection to the camera and everything goes well, DirectShow graph is built normally and everything just looks fine, besides the black frames. I can even open the camera properties and see it pushing out frames as usual.
Also, this only happens on Dell E6540 (With an AMD and Intel HD gpu) if it's Windows 7. Windows 8/10 work fine. Have tried a lot of drivers nothing seems to change the output.
I have no clue what to do or what to try.
After many hours and just after deciding to post this question, I found the answer.
The more complex solution, under the AMD Settings application was set to use "High Performance" mode, this mode was automatically enabled on Windows 7 for some reason. Disabling that and setting it to "none" or "lower power" fixed the issue.
Doesn't change the fact that there is an issue with laptops with dedicated AMD GPUs, probably something to do with DirectX/Direct3D which is used to render the frames.
Related
We are building a kiosk app and noticing some odd behavior with Google Chrome. To debug, we are monitoring all of the incoming events with monitorEvents(document); through the dev console and noticed 2 different kind of scenarios.
Eventually after a few minutes of heavy multi-finger/gesture use, we are stuck in a touchstart/touchend loop where touchend does not propagate down to a mouse/click event (breaking our app as we only handle onClick). It is continuously stuck in touchstart-touchend-touchstart-touchend for every finger click.
A continuation of scenario 1 with heavier use, we are getting absolutely no events in the console, not even a touchstart.
We are using Chrome 62 with Windows 10 with the following flags:
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe --kiosk --incognito --disable-pinch --overscroll-history-navigation=0 URL
We have tried to add --touch-events, add --disable-gpu, remove our previous flags, but still facing the same issue. It seems to be an issue between Chrome and Windows as we are able to replicate it on google.com (with getting no events). When we plug in a mouse, we are able to click the buttons so the app is not frozen, we are just not getting any touch events (only mouse works at this point). Touch is still working on the Windows and Chrome App level, just not our app viewport.
The kiosk is a Dell All-in-One machine. Has anyone else experienced this kind of issue?
Thanks!
UPDATE: Using Chrome 68+ I no longer have this issue. I have not tried versions between 62 and 68 to see where it was fixed but I am glad that it is!
It is a little late now, but maybe this will bring some closure. I experienced the same problem and like you, only in Chrome. The best I could determine was that this glitch is dependent on a particular model of touchscreen in the computer.
Check the hardware IDs for the touchscreen in Device Manager. Only the Inspiron 20-3059 models with a touchscreen made by Advanced Silicon (VID_2149&PID_4C39) exhibit this behavior. Other 20-3059 models with a different touchscreen model (VID_0457&PID_1192) work fine.
Oddly enough, later Inspiron 20-3064 models also work fine, though they also had Advanced Silicon touchscreens. The PID was increased to 4C3E so perhaps they discovered this issue and fixed it for the newer model.
I wasn't able to find any combination of driver/firmware/Chrome versions that would fix the problem, but this is as close to a root cause as I could get.
I grabbed this multi window test code, changed it to use D3DXCreateTeapot instead of D3DXLoadMeshFromX (I couldn't find a teapot.x file), moved the EndScene call below the DrawText call and set NUM_WINDOWS to 1. With those minor changes, the test works and creates two windows, each with its teapot.
I built the test and deployed it in a machine which has an Intel HD Graphics onboard GPU with two heads, each attached to a monitor. Then I moved one window to each monitor, and enlarged both windows to take up about 80% of each monitor space.
With this setup, which is quite close to what my app needs, the window in the secondary monitor always goes too slow. If I swap the windows, it's the same: the one in the secondary monitor starts crawling, and slows down the whole system.
I googled around and some sources (albeit dated) state that only the primary monitor can use hardware acceleration when not in fullscreen mode. I cannot use fullscreen because direct3d9 rendering in my app is done inside a user control embedded in a Winforms GUI.
Is it really impossible to get hardware acceleration for both monitors in windowed mode? The legacy version of our application uses MFC + DirectDraw and manages to perform fast enough, but those are obsolete technologies and we'd abhor going back there.
You have 3 options:
Try many combinations, like: D3DPRESENT_INTERVAL_IMMEDIATE +
(D3DSWAPEFFECT_FLIP or D3DSWAPEFFECT_COPY) +
D3DCREATE_ADAPTERGROUP_DEVICE. Maybe some will offer better
performance.
Render to a surface, convert to a bitmap, and use it like any other bitmap in your form. Something like this
D3DXSaveSurfaceToFileInMemory.
Change your code to DirectX11. You have more options for GDI interaction there. Better rendering behavior. Maybe better drivers.
Some years ago, I made some multiple window code, also multiple device, using DirectX10/11. I can't tell about DirectX9 having this issue, seems absurd to me, but could be your Windows version, or Intel driver.
Here is the situation. The company I work for builds this piece of software in c that can make a Windows computer act a bit like a TV. Essentially, our piece of software is meant to be played full screen and content is displayed from the internet without the user having to ever touch the computer again.
The problem is that once in a while, the system brings up pop-ups like "Your Windows system is ready for an upgrade." or "Please renew your Norton subscription" etc. which the user has to periodically and manually remove.
Is there a way to display content full screen without being bothered by those warnings?
Yah, whether or not the development community agrees, Microsoft has several standards for when and why it might be acceptable to have exclusive use of the monitor.
The most official strategy is to use DirectX in exclusive mode. This is what games do, what windows media player does in full screen video with hardware acceleration enabled, etc... If your application is multimedia intensive (as suggested by TV like functionality), you should probably be using DirectX too. Besides giving you the exclusive display access it will also increase your applications performance while lowering the CPU load (as it will overload graphics work to the video card when possible).
If DirectX is not an option, there are a great number of hacks available that seem to all behave differently between various generations of windows operating systems. So you might have to be prepared to implement several techniques to cover each OS you plan to support.
One technique is to set your application as the currently running screensaver. A screensaver if really just an EXE renamed to SCR with certain command line switches it should support. But you can write your own application to be such a screensaver and a little launcher stub that sets it as the screensaver and launches it. Upon exit the application should return the original screensaver settings (perhaps the launcher waits for the process to exit so that it returns the settings in both graceful exits and any unplanned process terminations ie: app crash). I'm not sure if this behavior is consistent across platforms though, you'll have to test it.
Preventing other applications from creating window handles is truly a hack in my opinion and pretty bad one that I wouldn't appreciate as a customer of such software.
A constant BringWindowToTop() call to keep you in front is better (it doesn't break other software) but still a little hack-ish.
Catch window creation messages with a global hook. This way you can close or hide unwanted windows before they become visible.
EDIT: If you definitely want to avoid hooks, then you can call a function periodically, which puts your window to the top of the z-stack.
You could disable system updates http://support.microsoft.com/kb/901037 and remove the norton malware.
You could also connect a second screen so that the bubbles appear in the the first monitor.
Or you rewrite it for linux or windows ce.
One final option is to install software that reconfigures your os into a kiosk http://shop.inteset.com/Products/9-securelockdown.aspx
If you don't need keyboard or mouse input, how about running your application as a screensaver?
A lot of thoses messages are trigged/managed by Windows Explorer.
Just replace it with your dummy c#/winform.
By changing the registry value
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="Explorer.exe"
You can specify virtually any exe as an alternative to explorer.exe
That's the way all windows based (embedded) system (ATM & co) do.
There's still few adjustment (disable services you dont need / dr watson & others), and of course, you'll want to keep a "restart explorer.exe" backdoor.
But that's a good start
I am writing code using VS.Net 10 and SlimDX to render 3D content on a D3DImage. It works perfectly under 32 Bit Windows XP. However, after migrating to 64 bit Windows 7 (quad core and 4 GB Ram), the same code does not work any more. The symptom is that after rendering about 10 or 20 times, the D3DImage's IsFrontBufferAvailableChanged event is raised and the property of IsFrontBufferAvailable has a value of false.
I have checked everything I can think of, e.g. RenderCapability.Tier, calling SetBackBuffer, checking the device (in fact it is DeviceEx type) after the front buffer is lost, updating video card driver (nvidia 9500 GT 1G RAM), etc. None of them worked.
One thing that may contribute to the problem is that the image control which uses D3DImage as the source is not created on the GUI thread. I am doing to reduce the work load of the GUI thread to make the application more responsive. Of course, I have been using Dispatcher.Invoke to avoid threading problems. Again, it works perfectly in XP.
Any help is much appreciated. Thank you in advance.
I think there is a x64 version of the slimdx.dll.. if you are using the x32 version, that could be the problem.
We have an old (Win32) and new (WPF) version of our blotter software, which the traders are currently running side by side. However, running the WPF application often severly slows down the redraw rate of the Win32 application.
Without the WPF application running (or minimized), draw rate is fluid and fast in the Win32 application. With the WPF application open alongside it, the Win32 appl's UI draw rate slows down noticeably. Running the WPF application seems to trigger use of some resources which are taken away from the Win32 app (both graphics-heavy) - causing the slow down it seems.
CPU and Memory are not anywhere near being saturated, so it doesn't seem to be related to those. Lowering resolution and/or reducing the number of monitors to display on (therefore decreasing video card memory usage and bandwidth load) makes no noticeable difference, therefore it doesn't seem to be a graphics hardware performance issue either.
One hypothesis that may explain the cause is as follows:
Under the hood, we know that both the WPF and Win32 applications output graphics information to a windows "message pump" which is basically a queue of instructions of what to draw to the screen. It seems as if when the WPF application is not running, the Win32 has full unfettered access to this and screen updates are fluid. Running the WPF application alongside it puts additional messages on this queue, so Win32 application has to compete harder for access to it (in order to do each screen element update), therefore "clogging the pump" giving the effect we see.
If the above is the case, can anyone recommend approaches to manage/control the window message pump in order to prevent this happening?
The flicker is the type you typically get when resources run low, where you can see individual elements (forms, labels) flicker and gradually draw on to the screen.
If anyone has any suggestions/ideas, let us know.
Each process will have its own message pump - this is not shared.
If you are not seeing high CPU utilization, then WPF is using hardware rendering, so it could possibly be GPU saturation. Can you get information on GPU utilization?
The following post details methods of getting GPU utilization:
Programmatically fetch GPU utilization
Okay, I think we've found the cause, and fix. In a nutshell, hardware and software accelerated windows don't play nice. Using software-rendering across the board fixes glitches that were previously there when running hardware-accelerated windows. Since our legacy Win32 app will be decommissioned soon, this is a workable comprimise - we can simply switch hardware acceleration back on when we drop the legacy application.
Notes below:
It seems like this issue is being caused by running a traditional software-accelerated 2D application (X) and 3D hardware-accelerated WPF one (Y) at the same time, and is a graphics driver issue.
Forcing Y to run in WPF software-acceleration mode as well causes little degradation in scrolling performance (as the bottleneck is still the grid's internal layout code).
However, what it does do, is get rid of the slow drawing issue in X, because Y is now running as a software-accelerated 2D application, like all other Windows applications on trader's machines. This explains why no applications other than Y caused slowdown - it seems as if software and hardware-accelerated graphics applications don't play nice when run at the same time.
This makes sense - when I play a hardware-accelerated game, for instance, I've seen similar (where the desktop redraws very slowly when switching to/from the game between hardware/software acceleration modes).
Thankfully we can turn off hardware-rendering without much impact in performance. Once X is decommissioned we can switch hardware-acceleration back on for the minor benefits it provides in Y (support for smoother animations and heavier use of fill gradients without slowing down etc).