I have a WPF application which has a DirectX component within it. This component does not work over Remote Desktop--it just shows a corrupted image. The application works fine when not using Remote Desktop.
In trying to debug the problem I installed the February 2010 DirectX SDK. Now, when I run the program on the computer with the SDK and Remote Desktop to it from a separate computer, the component works just fine. However the opposite does not work--trying to use the application over Remote Desktop when it is running on the computer without the DirectX SDK (it has the original problem with the corrupted image).
I have already compared the loaded DLLs (using Process Explorer) between running the application on my SDK machine and non-SDK machine. They both are loading the same DLL versions.
What else could be causing this behavior?
EDIT: I have discovered that the application actually is loading a different DLL. I didn't notice because I didn't capture the DLL list properly. When I run the application on the machine with the SDK it loads D3DREF9.dll, the DirectX reference rasterizer. This gives me a clue as to what the problem is, although I am still working out the solution.
It turns out that the application that I was maintaining was attempting to create a DirectX Hardware device, and if that failed, it would attempt to create a Reference device, and finally, if both of those failed, it would create a Software device.
There is no Reference or Software renderer available on systems by default. To get a Reference renderer the DirectX SDK must be installed--and you're only supposed to use it for debugging, not deployment. For a software renderer, the system only needs .NET 3.5 SP1 and then the software must load it.
Basically I believe the problem was that the software was failing to create the rendering device properly. I've cleaned up the initialization code and it renders over Remote Desktop just fine now.
Try reducing the performance/experience display options in RemDesk. I'd start with turning off Bitmap Caching, reducing the color depth, etc..
DirectX hardware acceleration is disabled by design for native remote desktop functionality: http://support.microsoft.com/kb/260565
Related
I have written a JavaFX app running on Windows 10 machine in the office which has problems showing (painting/rendering) certain embedded controls such as a Pane with PdfBox when I connect to it with Remote Desktop for Mac. It shows only a black screen in the app instead of the pdf document.
When I connect using RDP from my Windows 10 machine at home to my Windows 10 machine at work, the app works just fine (the pdf is shown in the app).
I have the same problems using AnyDesk and Teamviewer.
The app only shows PDFs properly using a connection from Windows 10 to Windows 10 with Microsoft RDP.
It might be a JavaFX issue. Similar issues are described here (although not 100% identical):
https://bugs.openjdk.java.net/browse/JDK-8239589
https://bugs.openjdk.java.net/browse/JDK-8229394
However, since I guess Microsoft Remote Desktop for Mac is using the same technology as the Windows Desktop client, I would have expected it to work fine.
I have a Mac Mini M1 running the latest OS (Monterey) at the time of writing this post. I am also using the latest Remote Desktop client for Mac.
This problem is not new and was also present in older releases.
I have tried to play around with screen resolutions, both on Host and Client but nothing good came out of those tests.
Disabled also hardware acceleration in Remote Desktop for Mac preferences but it didn't change anything.
The machine at the office has the following specs (which I cannot change nor update)
Edizione Windows 10 Pro
Versione 20H2
Data installazione: 10/09/2021
Build sistema operativo 19042.1415
Esperienza Windows Feature Experience Pack 120.2212.3920.0
Anyone else who has seen this problem and perhaps resolved it?
Could it be a bug in either PdfBox or Remote Desktop for Mac?
Except for the above issue, the Remote Desktop Client for Mac is working great (not lagging as TeamViewer or AnyDesk) and the user experience is phenomenal.
PS: While this might be considered a programming question (since I wrote the app with JavaFX) but it might be better to post on another forum? If yes, which one? On the other hand, many similar posts (look at the suggested thread on the right) have been upvoted despite not dealing with programming issues.
Thanks.
How do you use PDFBox? I ask because this is not a JavaFX component. If you use a SwingNode for that it might be interesting to try one of my two PDFViewer demos here and see whether the problem persists.
https://github.com/mipastgt/JFXToolsAndDemos#awtimage
The difference is in how I do the rendering and maybe that makes a difference for your use-case too. But of course this is just a wild guess and I can't promise anything.
I am using Android Studio 4.1.1 on Windows 10 20H2 with Hyper-V enabled on a computer with high DPI. Recently whenever I launch an AVD, the UI of the emulated device window becomes extremely large and impossible to use (as in the following screenshot). Other windows (including the AVD manager and the Android Studio itself) remains normal.
I have not used the emulator for a while, but I can make sure that the UI issue did not exist before I update my Windows to 20H2. I have also found similar questions on Stack Overflow (including this question), but the existing answers suggesting overriding its high DPI behavior does not work for me, because when I apply this setting, the emulator screen becomes so blurry that I cannot even recognize the texts on the screen.
How can I solve (or work around) this issue? Any help will be appreciated.
You can fix the scaling issue when using the Hardware rendering by simply making windows override the scaling setting. How?, it's very easy. Simply locate the .exe file for the emulator that you are using, (e.g. "qemu-system-armel.exe" for ARM and "qemu-system-x86_64.exe" for x86). To make sure which .exe file, just run the emulator then use task manager to locate the .exe file is running, see the screenshot. locate the .exe file using task manager
In my case it was in this location:
C:\Users[Username]\AppData\Local\Android\Sdk\emulator\qemu\windows-x86_64\qemu-system-x86_64.exe
Context:
I have a Xamarin Android project that calls a shared library (.so) and I'm using Live Player to run the app on my device.
Problem:
The app only runs fine sometimes. When it doesn't, I get no exception at Visual Studio and I only get a one-line exception from the Live Player on my phone as follows:
[LogEntry: Time=7/10/2018 4:42:26 PM -07:00, Level=Error,
Title=Visualization Error, Message=No body on method System.Int32
TestMobileLib.LibFacade::getInt(System.UInt32) (NInterpretException)]
Attempts:
I tried uninstalling the apk from my phone. It doesn't work all the time.
I also tried renaming the Android application package name to make it look like a new app. Doesn't work all the time either
Reinstalled the Live Player. No luck.
Re-paired my phone. No luck.
Tried it on a different device. Same random behavior.
Restarted the machine. No luck
Any assistance is highly appreciated. Thanks.
Thanks to the comments above by SuhiHangover and Bruno, I figured out the difference between running an app via Live Player vs. on the device itself. While Both solutions run the app on your device, the latter is much more stable at least when the project depends on a set of user-defined shared libraries.
As also noted in here, Live Player seems to be optimal to support rapid prototyping on device, where changes you make the front-end markup (e.g., XAML files) can be instantly synchronized wirelessly. Xamarin Live Player, however, is limited when more need to be tested. The list of limitations are mentioned here.
Installed Windows on my Galileo board and that works fine.
I developed a small application i Delphi7 (32 bit exe) that
I have deployed to the Galileo and configured it to start
at boot by configuration in the autorun.cmd file.
start C:\applications\GalileoApp1.exe
The application is formless and contains a TCPserver that echoes back incoming data.
Works fine under windows 7 on my PC.
Does not start automatically or manually on my Galileo.
Has anyone tried something similar and succeeded in executing the application on Galileo?
Are there any limitations on what types of 32bit exe´s that can be executed on the Galileo?
Stock Delphi RTL will not work on that version of Windows. The primary reason is that the Galileo versions of Windows' DLLs are different from the desktop version. This will require a rebuild of the RTL in order to import APis from their new locations. Some APis aren't even supported (such as most of the ones in GDI32 and USER32).
That being said, here at Embarcadero, as a research project I have a version of the Delphi RTL that does run on the Galileo board (I'm looking at the board right now :). I also have a stripped down Delphi conversion of some of the Wiring/Arduino Sketch API. When or even if we release such a thing is purely dependent upon the demand and our intended product direction.
The bottom line is that, yes, it is possible to get a Delphi-built command-line application (no visual VCL is supported, or anything that assumes the presence of a GUI). No, it's not a straight-forward, simple process as it requires some significant modifications to the RTL. I would also not recommend using Delphi 7, since the Galileo board doesn't support most of the Ansi versions of the Windows APIs. You will need a Unicode capable version of Delphi to start with.
I'am learning some Gamedevelopment using Monogame.
I started a Windows OpenGL Project and everything works fine on my Win8 machine.
I have compiled the project and sent it to 2 People, both are using win7 x64 and one of them can't open the Game.
After that, I tested it on my other computer (also win7 x64) and I get the same problem, the game process starts, then the screen flashes (Aero seems to deactivate), then everything gets back to normal and the process of my game crashes without a message.
I'm sure, that there is no problem with my code, maybe some missing dlls but most of them are copied with the game
Lidgren.Network.dll
MonoGame.Framework.dll
OpenTK.dll
SDL.dll
Tao.Sdl.dll
Sincerely
CarnVanBeck
If it's taking down Windows Aero, it might be a graphics issue. Compare the graphical capability of the Win7 machine that can run it with the one(s) that can't. Does the working one have a graphics card? I seem to remember Monogame having odd behaviour with the Reach graphics profile.
Ok I fixed it using an OpenAL32 installer
I found the solution here
You have to install it, if your game doesn't work.
fixed it for me on my second computer.