I'm working on a fairly big Swing-based app (JPanels, JLabels, etc) and I have to find out why text-antialiasing (on JLabels etc) is not working.
As you may know, antialiasing normally works automagically (with Java 1.6 anyway), that is, when one creates a simple Swing-app (for example, just a JPanel with a JLabel on it) the text on the JLabel will be antialiased out of the box. No need for System.setProperty("awt.useSystemAAFontSettings","on") and/or System.setProperty("swing.aatext", "true").
But this app is different, it does not antialias out of the box, it does not antialias with System.setProperty("awt.useSystemAAFontSettings","on") and/or System.setProperty("swing.aatext", "true") in the main(String[] args), on also not with -Dawt.useSystemAAFontSettings=on and/or -Dswing.aatext=true as VM-arguments. I've tried these and other all suggestions I could find on this site and on internet, but to no avail: this app just never antialiases, whatever I do or don't.
I'm out of options now. So my questions are:
What steps can I take to find out why antialiasing is not working ?
What properties should I check ?
What code should I trace with the debugger ?
What circumstances could cause antialias not to work ?
All insights are welcome.
Try the advice in System Properties for Java 2D™ Technology: awt.useSystemAAFontSettings.
As of 1.6, it looks like swing.aatext is ignored. However, as noted by #Andrew, awt.useSystemAAFontSettings should work...
One of the things you might want to do is dump out the Map for the awt.font.desktophints desktop property just to see what, if anything, has been set.
Related
I have a Sikuli script written in java to click the windows start button and then click "All Programs" as appear. The script works absolutely fine on my computer but when I transfer the same script to another computer, it doesn't work.
Code:
Screen screen = new Screen();
screen.type(Key.WIN);
screen.click(IMAGE_DIR + "program.PNG");
I used concepts like Wait, Pattern and similar but not able to solve this issue. Not sure if this is a limitation of sikuli.
Like was already mentioned in the comments, differences in screens resolutions will definitely ruin your existing scripts as Sikuli is super sensitive to them. In such case, the only solution is to recapture the patterns and use a different set of them on each machine.
However, if you have such issue but screens resolutions seem to be identical, there are few more things that should be checked.
Clear Type, which is Microsoft's implementation of subpixel rendering that is supposed to improve the fonts visual appearance. If you have this feature switch on on one machine and switched off on another, that might be an issue.
Smooth Edges of screen fonts setting that can be found in the "Visual Effects" settings window in "Performance Options". It does exactly what it says, smooths windows fonts to improve the looks. As in the case of ClearType, this feature should be switched off or on on both machines you run your scripts on. The general recommendation to have the always off to avoid this kind of issues.
For those still using Sikuli and experiencing inconsistency when running across different machines, it's helpful to debug on the boxes that are showing the issue.
Some things like issues around various AppData temp files not being managed correctly can show up in some PCs but not others. It's a pain to install your IDE into different places but it sometimes is the only way to really see what's going wrong - and be able to fix it.
How can I make it so Eclipse automatically updates my code in a window as I edit it? I've seen the feature before in youtube videos but I cannot find it. For example : I change a JApplet rectangle width from 20 to 10, I want to see it update immediately.
I've seen Notch do this on development videos (Minecraft), it is awesome but I don't know exactly how he does it.
-- EDIT --
This has been bugging me so I went and googled "how does notch code" and found this on a blog page https://gun.io/blog/what-i-learned-from-watching-notch-code/. It doesn't say exactly how it was done but gives a good hint (HotSwap) and makes it seem like he set it up himself without external software. Here's the most relevant section:
Incredibly Fast Testing
He began by building the engine, and to do this he used the ‘HotSwap’ functionality of the Java JVM 1.4.2, which continuously updates the running code when it detects that a class has changed.
When building the engine, Notch wrote a function which would continuously pan the camera around and clip through the walls and keep the view on top, so he could make changes to the code and see the effects they made in real time. I’m used to testing by writing a function, building it, installing it on the device I’m testing on, and then seeing the result, which can take up to a minute at a time, so it’s easy to see how HotSwapping could save a lot of development time.
--- ORIGINAL POST CONTINUED ---
I get a similar effect by using groovysh though, works smoothly and can use all your java classes as is.
What I'll usually do is write all my code in java, then go and fire up "Groovysh" where it will give you a little window to enter commands (You may have to ensure the classpath works correctly outside of eclipse). I can then "new" any of my classes and call methods on them one line at a time. When you do myFrame.setSize([100,100]) you will see it change immediately.
A good test is to just run groovysh and type something like:
import javax.swing.*
f=new JFrame()
f.setVisible(true)
f.setSize(100,100)
or the groovier version:
f=new JFrame(visible:true, size:[100,100])
and you will see your frame resize on the screen. You can even drag it bigger and then do something like:
println f.getWidth()
to show your new width. It's fun to interact this way but it's more complicated if you want to actually change your class definition and see it pick up the change, I have no idea how Notch did that. I looked into it a little--it's possible he was using something like JRebel
It requires something special since you would have to dynamically reload the classfile into your running system on every save--something that should have serious classloader issues.
By the way there is also a way to get your Java program to throw out a little GroovyConsole which will allow you to inspect and modify all the variables in your running code (but again you can't replace definitions of existing classes).
Also see answer here:
Change a method at runtime via a hot swap mechanism
I have made a Screen Recorder using Java Swing and Xuggler 5.4. I have developed it in Windows 8 64 bit. It's working excellent for Windows. But at client side on Linux's environment , nothing is working. I have searched thoroughly but not getting any solutions. I have checked this thread , but it didn't work for me.
Then I tried to create simple Transparent window in Linux but it's also not working. I was not able to click through the Resizeable Panel. I have used the same JRE version (1.7) for both. Have I miss understood Java's Cross Platform Support as far as Swing is concerned?
Please Give Me Some Advice...
I have always found logging to be the best debugging tool at your disposal! Many a times, java debuggers take you into APIs where you need not go every time. Logging values of your variables, and generic 'I have reached till this point' statements make life a lot easier.
So, I suppose you have ample logging done in your code. That could give you clues on what's happening on your client's system.
Are the right environment variables set? Are they pointing to the correct Java versions you need.
If there are some specific Screen capturing requirements(plugins / modules / API) your code has, are they available on the Linux m/c?
Like #MadProgrammer said, in the end, Java has to talk with the native graphics APIs to render your screen.
I would try to debug it in this way -
Check whether my main screen loads or no(by disabling the screen capture functions for a while).
if not, dig deeper.
Check whether all necessary components for capturing screen(audio and video) are available.
Check whether the code is being run with appropriate permissions to control the h/w devices you may need.
I have a web application (struts 1.3, Weblogic 10.3.0, Toplink, Oracle) that has a Java applet which isn’t working in the browser (IE7/8) when the Next-Generation Plug-in setting is enabled in the Java control panel but works fine when it’s disabled. The trouble is that this setting is set to disappear in an upcoming Java release meaning that my users would have to keep using Java 1.6_xx on their workstations as they are currently. I have little influence over which version they use because they are all governed by their local IT departments across the country. So, either I have to find a simple fix to allow the Next-Generation setting to work, or we have to look at replacing/rewriting the applet with something else (but would be a last resort due to funding constraints), most likely something AJAX-friendly so as to avoid the need for a plugin. This application is quite old, written around 2001 before AJAX was really around.
The main window has a left, right, and top frame (JSP’s), as well as a center frame which is where the applet is. The applet has a main content area in the middle and a lower panel at the bottom which has some buttons. The buttons tell the content area (which is basically a treegrid) what to do (Save, Copy, change status, etc ). When I press one of the buttons the entire window (surrounding frames plus the applet itself) repeat inside the area where the applet is. It’s like a kaleidoscope or like a repeating fractal pattern kind of thing, or like when you take a picture of yourself in the mirror and you see the room repeated over and over in the mirror. In this case it repeats for each button press and the repeated set gets smaller each time. Weird!!
So, based on my research, the Java Next-Generation plugin works differently by allowing more than one process or thread whereas the classic plugin only uses a single thread. So my suspicion is that a new process is being spawned for each button press. I tried using the “separate_jvm” applet parameter but it made no difference whether it was set to true or false. I don’t see any other applet parameters which seem to be relevant.
Another idea I had is that maybe it’s something to do with the JSP frameset, maybe something like “target=_top” needs to be added somewhere…but I’m not sure how this relates to applet threads if at all.
Anyone have any suggestions, ideas or experiences that might help?
you can use velocity to handle these type of problem and it will also help you for future enhancement also.
The problem is not related to version of IE but rather to version of Java. Below excerpt from letter of certificate provider (they took it from some forum, so direct link to source cannot be provided):
For JDK version higher than 1.6.0 and below 1.6_15, you can just
clear all kinds of cache in web browser, java console and java control
panel. Then it should works fine!
For JDK version between 1.6_15 and 1.6_30, you should disable the "next-generation java" option in java control panel.
For JDK version higher than 1.6_30, you should turn on "next-generation java" option in java control panel.
When I installed inconsolata everything looked fine, however when I tried viewing it on netbeans it look like this:
I tried using both the ttf and otf versions and they both looked messed up.
Is this a java issue? Win 7 64 bit issue? Is there any way to fix this?
You could try disabling font antialiasing in NetBeans.
Open up your netbeans.conf
As part of the netbeans_default_options section add -J-Dswing.aatext=false -J-Dawt.useSystemAAFontSettings=off.
Edit: fvu also provided a helpful link to a relevant section in the NetBeans font rendering FAQ.
If you want to play around with NetBeans font rendering settings, take a look at http://wiki.netbeans.org/FaqFontRendering
Unfortunately, what this article concludes is that default font rendering settings provide the best possible experience. At least under Windows. I have tried all the possibilities with Inconsolata and defaults provide the the best look indeed.
As a workaround, you can try two things:
Decrease contrast of your color scheme, i.e. by decreasing lightness of a background and/or increasing lightness of your font. It makes font rendering issues less visible.
Use NegativeScreen: http://arcanesanctum.net/negativescreen/
You may find your experience improved, but this is up to your personal preference.
It's not just NetBeans, although it is probably not simply the Inconsolata font's fault either. There seems to be a problem at the level of the underlying Java system that NetBeans is built on. I say this because the exact same problem shows up in the IDEs created by Jetbrains -- IntelliJ IDEA, WebStorm, PyCharm, and possibly others.