I wonder if my standalone application that gui is being made using JavaFX 2.1 would run on a quite old computer with Windows XP, because this app is intended to work on that computer. I'm asking because I'm begginer to JavaFX and it seems like that technology has quite high requirments, last time I've got warning: "bad driver version detected, device disabled. Please update your driver to at least version 8.15.10.2302".
If your machine meets the minimum system hardware requirements and you have a recent graphics driver installed, then JavaFX 2.1 should work on your Windows XP machine.
Whether JavaFX will work on a machine depends on the hardware in the machine as well as the graphics driver installed.
Here are the JavaFX 2.1 system requirements.
The version string you reference would appear to be for an integrated Intel chipset graphics driver. You can download current versions of such drivers from Intel.
Update
If your system does not support hardware acceleration, then JavaFX
uses the Java2D software pipeline" - just to be sure, my program will
still work, but with poorer graphic, right?
At least in some cases with older drivers, it would seem that the app will work by falling back to a software pipeline. While this kind of fallback will work for a large percentage of older hardware and software combinations, I don't think it is fully tested given a wide variety of older hardware and driver combinations and I don't think there is a guarantee that the program will still run as expected.
The below outlines my experience with JavaFX 2.0 and 2.1.
If the graphics hardware is not listed in the JavaFX system requirements as being supported for hardware acceleration, then JavaFX will fall back to the software renderer and the app will work (albeit with potentially reduced performance and lack of access to some conditional features such as (perhaps) effects or 3D rendering). This scenario should be pretty uncommon as JavaFX supports a wide variety of hardware acceleration hardware.
If the graphics hardware is listed in the JavaFX system requirements as being supported for hardware acceleration and the drivers are up to date, then JavaFX will use the hardware renderer and your app will work. This is by far the most common scenario - any desktop purchased in the last few years should meet the minimum JavaFX hardware acceleration specifications and driver requirements.
If the graphics hardware is listed in the JavaFX system requirements as being supported for hardware acceleration and the drivers are not at a level required for JavaFX to function correctly, then the app may not work (the app may fallback to the software pipeline and continue running or you may get a message stating that the drivers need updating) or the app will just start experiencing rendering errors and possibly freezing or crashing. This scenario should only occur on a very low percentage of possible runtime targets.
If you have instances of hardware and driver combinations where JavaFX is not behaving as you would wish (i.e. not correctly executing your program, logging spurious exceptions or freezing and crashing), then file a jira issue with the hardware and software specifications to get the JavaFX team to look into providing support for that combination.
Related
I have been working with QML for a couple of weeks now. But now a new requirement has risen where I have to check whether I can run QT5 in an embedded device for my project. I need this for my GUI related operations. The device has an ARM processor (Intel ARM920T-PXA27x processor to be exact) with 64 MB RAM. 32 MB will be taken up for the OS and the rest will be available for application and QT.
I have to check whether this is possible. I have googled for some references and unable to find a suitable answer to my requirement with QT5. I need the GUI libraries but my project does not have advanced graphical requirements like swiping or animations. It contains basic controls like texts, buttons and lists/grids. Since I am new to QT especially to this part, I would like to hear whether
1) Is this a viable option and should I keep digging more into this? Any feedback would be welcome to know if it's worthy to spend time to attempt this or if it's a lost cause.
2) If there are options, could you point me in the right direction to look more into this?
It depends on the OS you are running on your SOC.
It's definitely possible when running Linux. You can e.g. use Qt Lite for configuring a minimal static build of Qt. Then you deploy your statically linked application to the device. You can check this blog post for experiences with Qt Lite.
One possibility is to go with Qt for Device Creation for the whole embedded Linux based software stack which boots to a UI implemented with Qt technologies.
We are converting directx9 to directx10 and we are getting an error: Cannot open include file :dplay8.h .
Please provide the solution how to resolve this and also the steps that might required to convert from directx9 to direct10.
DirectPlay is a deprecated legacy component. The last version of the legacy DirectX SDK to include the headers for it was August 2007. See DirectX SDKs of a certain age. It is not available in any Windows SDK.
It exists in the Windows operating system today for appcompat only. There are a number of important limitations to keep in mind:
DirectPlay Voice is not supported on Windows Vista or later operating systems. See KB970978
The NAT helper object is unsupported on Windows Vista or later
On Windows 8.x and Windows 10, DirectPlay is an optional Windows feature so it's not present by default. It has to be enabled by the user.
In short, you shouldn't use it. You should plan to rewrite the multiplayer support for that porting project, or strip it out.
DirectPlay's primary value was back when networking was a complex and evolving world: modem play, head-to-head serial ports, IPX/SPX, TCP/IP over modem, and TCP/IP. At this point TCP/IP is the only network solution that matters so using WinSock directly is far preferable. There's are also a number of security implications around use of UDP (datagram) vs. TCP (virtual circuit) that modern games need to take into account. The lobby mechanism of DirectPlay is also woefully outdated.
There are numerous modern game services (such as Xbox LIVE, Valve's Steam, etc.) that are designed to provide the match-making, NAT-traversal, and other features that are essential to modern multiplayer. You use WinSock in combination with service-specific libraries.
In a related note, there is absolutely no reason to use DirectX 10. DirectX 11 supports much more hardware, is supported on all the same operating systems (Windows Vista SP2+), and has numerous replacements for legacy support libraries that don't exist for Direct3D 10.
The upcoming Qt 5.6 introduces a blacklist to mark some graphic cards which are known to insufficiently support OpenGL or Angle.
Confirm e.g.
https://bugreports.qt.io/browse/QTBUG-47435
https://codereview.qt-project.org/#/c/140418/5//ALL
But what happens to QML apps on cards that have both disable_desktopgl and disable_angle set? Can those users not run QML apps at all?
They can't use OpenGL to accelerate Qt Quick, no. Which is a pretty severe drawback. Unfortunately the status of OpenGL on Windows is a nightmare. The "average" Windows computer will have an Intel-based GPU with ancient drivers, which are buggy enough to cause Qt not even try to use any 3D at all (OpenGL nor Direct3D). NVIDIA and AMD are usually better, as at least they tend to be more up-to-date.
Usually upgrading the Intel drivers solves most issues, but you are not always in the position of asking your users to upgrade their drivers (they might not even be able to do so, for instance lacking administrator privileges, and/or using laptops where the driver version has been pinned by the vendor).
Note that even other projects, such as Chromium or Firefox, have their own fine-grained driver bug blacklists (example).
In case your card is totally blacklisted you can:
use an OpenGL CPU implementation, such as Mesa. If you ship opengl32sw.dll with your application, it can be picked up by Qt. See the explaination here.
use the Qt Quick 2D renderer, which is a specialized CPU-based renderer for a subset of Qt Quick items. Compared to Mesa it's incredibly faster (because it doesn't need to go through the OpenGL pipeline in order to draw, say, a rectangle -- it can just draw the rectangle using a 2D rasterizer); on the other hand, certain things stop working, like shader effects. Currently it's available only under a commercial license, but in 5.8 it's going to be open source.
(Nitpick: QML is the language, Qt Quick is the framework/library to build UIs which you program using QML).
I have a telecom desktop application(EMS) developed in java Swing. Its an old application developed and maintained in swing from last 10 years. Now we are planning to update GUI pages using javaFX technology for better and clean look & feel.
I had gone through various stack overflow discussion stating difference between javaFX and Swing. Please someone help me to understand the challenges in upgrading to javaFX GUI considering below constraints:-
-Application needs to be deployed in Unix, Solaris, HPUX, MAC and window 7/8 OS
-Some third party jars are also used along with JRE
-Current supported JRE is java 7
-There could be a plan to support android/apple/blackberry handheld devices
-We are not using Database for persistence but live data to display.
This answer is based on the detailed constraints of the question and is not a general comment on Swing to JavaFX ports. Parts of this answer will inevitably get outdated, perhaps fairly quickly.
Given your constraints, you can't upgrade your application to JavaFX.
Solaris and HPUX are not supported deployment platforms for JavaFX and that is unlikely to change.
The only way you could get JavaFX to work on Solaris or HPUX would be to use an unsupported configuration such as running a VirtualBox VM on Solaris or HPUX as the host OS, and in the VM run a supported OS, such as RedHat 6 or Oracle Linux 6, then running your JavaFX application within the supported OS - this may or may not work.
Also, I think it unlikely JavaFX would be ported to run on blackberries any time soon. There are ports of JavaFX to other mobile platforms, and they work for simple applications. I haven't tried them and think of JavaFX applications targeting such ports as a bit experimental at this stage. Such ports do not execute on an Oracle JVM and JRE, so if you use external libraries they have to be compatible with the port runtime (e.g. the Android Development Kit, RoboVM libs etc).
If you ported parts of your application to JavaFX, I would recommend running on a minimum of Java 8 rather than Java 7. Many bugs were fixed and many new features were implemented in JavaFX for Java 8. In particular for a Swing->JavaFX port, the integration capabilities of JavaFX and Swing were improved in Java 8 with SwingNode. To help ensure your target systems have the correct runtime installed you can package your application with an appropriate JRE as a self-contained application.
Of course, if you can relax your constraints a bit, there are many positive points for JavaFX.
I have a system with an NVidia graphics card and I'm looking at using openCL to replace openMP for some small on CPU tasks (thanks to VS2010 making openMP useless)
Since I have NVidia's opencl SDK installed clGetPlatformIDs() only returns a single platform (NVidia's) and so only a single device (the GPU).
Do I need to also install Intel's openCL sdk to get access to the CPU platform?
Shouldn't the CPU platform always be available - I mean, how do you NOT have a cpu?
How do you manage to build against two openCL SDKs simultaneously?
You need to have a SDK which provides interface to CPU. nVidia does not, AMD and Intel's SDKs do; in my case the one from Intel is significantly (something like 10x) faster, which might due to bad programming on my part however.
You don't need the SDK for programs to run, just the runtime. In Linux, each vendor installs a file in /etc/OpenCL/vendors/*.icd, which contains path of the runtime library to use. That is scanned by the OpenCL runtime you link to (libOpenCL.so), which then calls each of the vendor's libs when querying for devices on that particular platform.
In Linux, the GPU drivers install OpenCL runtime automatically, the Intel runtime is likely to be downloadable separately from the SDK, but is part of the SDK as well, of course.
Today i finally got around to trying to start doing openCl development and wow... it is not straight forward at all.
There's an AMD sdk, there's an intel sdk, there's an nvidia sdk, each with their own properties (CPU only vs GPU only vs specific video card support only perhaps?)
There may be valid technical reasons for it having to be this way but i really wish there was just one sdk, and that when programming perhaps you could specify GPU / CPU tasks, or that maybe it would use whatever resources made most sense / preformed best or SOMETHING.
Time to dive in though I guess... trying to decide though if i go CPU or GPU. I have a pretty new 4000$ alienware laptop with SLI video cards, but then also an 8 core cpu so yeah... guess ill have to try a couple sdk's and see which preforms best for my needs?
Not sure what end users of my applications would do though... it doesnt seem like they can flip a switch to make it run on cpu or gpu instead.
The OpenCL landscape really needs some help...