I'm working on a Swing application (currently running on Java 1.6 update 11) which has some intermittent paint refresh problems (e.g. there are artifacts etc.). This only happens to some users of our application but not others.
After doing some research, I found that setting the property sun.java2d.d3d to false may help and in fact, it helped for one of our users.
Now that some other users are complaining about the issue, I'm thinking of setting the property to false for all users.
My basic questions are the following:
What exactly is the cause of this? Is it the video card? Is it the driver? Is it a bug from Sun? (such as http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6635462) Combination of all three?
In other words, is is best to simply turn this property off or is it affecting only certain video cards in which an update to the latest driver would fix?
Java introduced in R6 update 10 a pipeline that renders graphics based on Direct3D. According to the release description here it supports only NVidia and ATI cards, which means anyone not using those cards may have a problem. Since it is a recent innovation I would suggest that anyone using old drivers for those cards may also have problems. Upgrading a video driver will probably fix the first case but not the last.
If you set sun.java2d.d3d to false the worst that can happen is that some users will not achieve the performance that they theoretically could. You will have to balance whether this is preferable to the issues that you are seeing at the moment.
Are all painting and model changing operations execute on EDT (e.g. changing TableModel etc.)?
Related
My machine seems to be experiencing some weird issues with java swing.
This sort of thing happens with other programs as well but the corruption goes away with scrolling or highlighting the text. What could be causing this and why doesn't java go the same? All the characters seem to be cached so that when a character gets corrupted, all of the characters of the same type have the same corruption (not true of anything but java swing).
I have been googling around for this sort of issue but most of them only suggest issues with graphics drivers and settings for windows... (I am running kubuntu)
Side note: Sorry if this doesn't belong here. Didn't really know where else to ask.
Among the many possible causes,
Verify that all correctly synchronized Java Swing programs using standard font families with the default Look & Feel exhibit this behavior; if not, it may very well be a driver problem.
Investigate whether the Ubuntu video driver permits alterations similar to the one required in this Windows case.
Try a different window manager.
Try a different Look & Feel.
I recently came across a bug with an unresolved issue in SDK 2.2 and, as its fixed in 2.5, decided to explore a switch.
Now I am new to GWT and I have no idea of the effects of doing such a switch, but figured it couldn't hurt to mess around locally. I went ahead and successfully updated to 2.5 locally to test and can run with no errors. However many of the text boxes have changed appearance and my navigation bar disappeared, etc...
Is this type of behavior normal after an update? If so I cant imagine why anyone would be in a hurry to do so, as spending enormous amounts of time to modify all pages is pretty unrealistic. Is there maybe some type of quick fix or an error i may have made to cause this?
If you want to put a lot of resources into a GWT project it is always a good idea to check regularly how the project is going on. On the release-note page you can check what's new and what has been deprecated. This way you can make an informed and rational decision whenever you want to update. This is very important since going from an old version (say 1.0) to a new one (i.e 2.5.1) might give some headaches to the programmers. Spendind half-an-hour checking what's going on every month will make your life easier.
GWT has an issue tracker where you can see the open issues and what has been resolved. Many issues have never been fixed, but I read the GWT team intend to solve the 100 most important issues for the next release. GWT is now open-source and you can contribute to its development whenever you know of to fix one of those issues.
Last but not least: many people say a lot of things, which are not always correct (including on Stack Overflow). Always dubble check before making important decisions.
Giving this advice is all I can do for you so far...
Yet, if you give me some info about that bug you expected to be fixed and the exact name of that "navigation bar" widget you might find out information on the sites above to check their status. But I can't search that for you if I don't know what the bug was and the name of the widget that is broken. Also, when you say "many of the textboxes" I understand it's not every textbox that's broken but some variant your are using in some particular places. More information would also be needed...
Does anyone face this problem?
Applet disappear when another frame is reloaded in IE10.
I found a related bug report in Java bug Database
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193503
Any other solutions beside trigger repaint()?
By the way, how to vote the bug in Java Bug Database?
Any other solutions beside trigger repaint()?
3 posibilities jump to mind.
Launch the applet free-floating using Java Web Start.
Don't use frames.
Use an earlier version of IE, or a different UA.
By the way, how to vote the bug in Java Bug Database?
Step one is to join the OTN. Note that OTN members have complained about not being able to access the bug DB.
I have tried to trigger repaint() which still cannot solve the problem.
I think the components positions in applet are wrong after the frame is reloaded.
The workaround is resize the window by Javascript call.
I have recently found out that anything Swing(NetBeans, IDEA) is excruciatingly slow to paint the UI over Remote Desktop(RDP).
Can you guys give me any suggestion for something that will work properly over RDP?
Actually, contrary to everything I've seen - mostly the "Dsun.java2d.noddraw=true", which is mentioned in a number of places, it is actually setting it to false that fixed the drawing issues(for me at least). Go figure.
RDP is optimized for native Windows apps and, regrettably, newer versions of RCP (like Vista/Win7's default RDP) is even more hostile to non-native apps than older (XP/Server 2003) versions. Here's a good link:
http://devnet.jetbrains.net/thread/280673
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4204845
One workaround is to get a screaming fast CPU/graphics board, tons and tons of memory and a super high-speed network connection :)
Another is to:
Select "32-bit true color" in your Terminal Services settings
Select "Modem"
Reduce screen resolution (heck, use 1024x768 if possible)
Here are some additional tips:
http://www.codinghorror.com/blog/2006/04/remote-desktop-tips-and-tricks.html
Try setting "Dsun.java2d.noddraw=true"
http://ubuntuforums.org/archive/index.php/t-1129187.html
http://www.mindfiresolutions.com/Solving-DIRECT-DRAW-ddraw-problems-in-Java-Swing-730.php
I am launching a java swing application from Linux, and display it as a Windows frame thanks to MobaXterm.
If you haven't done it already, please have a look at the following documentation :
https://docs.oracle.com/javase/8/docs/technotes/guides/2d/flags.html
Using -Dsun.java2d.noddraw=true did not fixed my issue, but setting xrender to true did.
So here's the code I used on Linux :
export _JAVA_OPTIONS='-Dsun.java2d.xrender=true'
java -jar my_java_application.jar
Maybe it's not only Swing that paints slow over Remote Desktop. However, Eclipse is based on SWT, based on native widgets, so it is not Swing.
You should give JavaWIDE a try. It is an IDE designed for access to a JDK without it installed on a system, with a built-in storage system so you just need access to the internet. It's not exactly a program for accessing everything on the computer but it will do a good job with your programming. It may take a while however, as the compiling is done on a separate server.
The swing-UI of Java-programs doesn't work perfectly together with the awesome-wm. awesome is a window-manager for UNIX, that automatically resizes program-windows, and the Swing-UI doesn't recognize these resizes correctly. I don't care if awesome or Java is guilty, what I wanna know if I can change my Java-programs in a way, that they will work with awesome. So that users of my programs get the correct experience, even when they use exotic window-managers.
Easiest workaround - get wmname from suckless and use it to set the name of the window manager to LG3D:
wmname LG3D
98% of the time this will fix the issue.
From the man page of awesome:
BUGS
Of course there´s no bug in awesome. But there may be unexpected behaviours.
Java applications which use the XToolkit/XAWT backend may draw grey windows only. The XToolkit/XAWT backend breaks ICCCM-compliance
in recent JDK 1.5 and early JDK 1.6 versions, because it assumes a reparenting window manager. As a workaround you can use JDK 1.4
(which doesn´t contain the XToolkit/XAWT backend) or you can set the following environment variable (to use the older Motif backend
instead): AWT_TOOLKIT=MToolkit
You might find that this is a similar problem to that experienced with using Compiz and Java (on Ubuntu at least), but I am guessing.
The fix for this (taken from here) is to add the following environment variable to your program:
AWT_TOOLKIT="MToolkit"