I am working with an application that is experiencing painting issues on some users computers when the mouse passes over the tabs in a JTabbedPane. They also occasionally have similar issues on other interactive components like JButtons. I have only ever seen this error occur on mouse overs.
The application is being run with 1.6.0_20 and I have already tried the flag recommended in update 10 in case it was an issue with D3D (-Dsun.java2d.d3d=false).
Since I am a new user I cannot post a picture to illustrate this error. The best example I can think of is using Windows paint eraser on an image would create something similar to what I am seeing.
I appreciate any help you can provide.
Without an sscce that exhibits the problem you describe, it's hard to be specific, but this reminds me of the rendering artifact associated with setting the opaque property to true without completely rendering the area defined by a component's bounds. In particular, if you override paintComponent() and "do not honor the opaque property, you will likely see visual artifacts." Finally, the default opacity setting of some components varies by Look & Feel, so the effect may be platform dependent.
Related
I want to change the color of the title bar and also the Java icon on the upper left of the frame, so I can make my program (GUI) look better. Is there a simple way to change it?
I'm not sure how useful this observation is, but under the X Window System (e.g. on Linux), the titlebar and the icons in it aren't usually under the control of the application, they're “decorations” under the control of the window manager (WM). I'm not sure exactly how this might impact a Java program — they might be able to use undecorated windows and add their own equivalent — but it's equally possible that what you want to do simply isn't possible (without an inordinate amount of effort) on any platform.
Typically, when I create a class, for example Customer, I give it some data fields, i.e. public int IdNumber; and some methods, i.e. public String getName(){...}. But that's pretty much it. I can't go beyond that and start playing with graphics - I can only manipulate and organize data as far as the class allows.
I can't get my head around what is happening inside JFrame. Whoever wrote the class JFrame, how did they write a class that can make a box appear on screen? What is happening internally that causes this to happen? Is there anyway to emulate it?
The same question applies to all graphics-based Java classes. I'm really curious to know how it works, as it bothers me each time I use one of them.
Java started with awt (Abstract Windowing Toolkit) and later introduced swing.
In AWT the platform event handling loop is hooked into, and events are packed in own java classes and one single (non-parallel) event handling queue/thread handles them, one after another. Swing inherits this.
In AWT every GUI component, like radio button or menu item, has a native code "peer" control, the platform provided component. There is a parallel set of java classes and their C counterpart. Especially interesting is the java Graphics class which allows custom drawing of lines, rectangles and such. It is peered under Windows with a CDC (Device Context) - presumably.
In Swing most of the platform components are emulated, that is, recreated oneself: the drawing, the mouse handling, and so on. So the native part is simpler, say maybe a CWnd (Window component) with custom drawing.
Swing can achieve a more consistent and more feature rich functionality. You can imagine that setting a backgroud color on an AWT radio button might not be possible, or using HTML on a label or tool tip. Also Swing can do skinning, themes, LookAndFeels. The System look and feel being a close imitation of the platform components. Especially Swing components are more light weight, as not every component has a native peer control to be handled in C.
Now SWT was a later initiative of IBM realized in eclipse for AWT reloaded. Not as customizable as Swing but intended to be platform near.
You should forget using AWT components, and if not programming for eclipse RCP also SWT.
So: global platform events like mouse click, repaint request are translated to Java events. There is a container hierarchy of JFrame, JPanels, JScrollPanes, JComponents. An event is dispatched to the handling components, on which for example paintComponent is called:
#Override
public void paintComponent(Graphics g) {
Graphics2D g2 = (Graphics2D) g; // A later introduced class that can do more.
g2.draw...
}
With JavaFX there comes a new player, which is IMHO not yet fully mature, but usable in non-production code. It enables effects/animations, rotations, transformations, light. So a 2D - 4D rendering, based on like platform rendering. Also it is property based, so a check box would not necessarily be bound to a boolean, but a boolean property observing and notifying changes. I need still some practical experience, to conceive an optimal architecture with it.
If you are curious about how java is implemented you should take a look at the source code. http://openjdk.java.net/projects/jdk7/ would be a start.
Of course this would only give you insight into that particular implementation and doesn't mean that your java is implemented the same way.
How does a box appear on a screen? This functionality is offered by the operating system to the JVM (by the X Window System on Linux).
On the Java level, JFrame inherits from java.awt.Window, which has the "native peers" provided by the native windowing system.
If you really want to understand it, it is better if you try to create some windows using C only.
I have a number of various components in a very large JavaEE application. As such, debugging is a pain, and sadly I cannot provide an SSCCE that accurately depicts the problem I'm having.
In a nutshell, somehow my fonts change by themselves for things like JLabels and JTabbedPanes. Without ever touching them, they're being repainted as bold, italicized, dramatically changed in size, or any combination thereof.
Simple question: why?
If I step through the Eclipse debugger, no changes are made, ever. So time is somehow a factor.
I'm still a Java grasshopper (working by myself), and haven't built this program in such a way that the EDT is a sacred object. I'm worried that because I'm potentially not making all repaint() calls on the EDT that the JTabbedPane, JLabel and other font properties are being reset and repainted.
EDIT:
Forgot to say that I'm constrained to Java 1.5.
I think I've narrowed it down to an issue with using HTML in JLabels and JTabbedPane tab titles...but past that I've got no idea. With regards to the JTabbedPane, it's going into the drawing methods with the right Font/FontMetrics objects, but for whatever reason it will very rarely (sometimes more often; still haven't figured out the timing trigger) switch up what font, style, and even size at which it's painting the text.
I've got a problem, that swing components in different parts of program have sometimes wrong background. For example this or this.
As I mentioned, the bug is not permanent and it can appear in one place one time and never after. But still there are some places, where I can randomly reproduce it. Unfortunately, I don't see any solutions.
Has anyone some ideas how can I fix it?
If you set your components to non-opaque (I think the call is setOpaque(false)), that will let the background colour of the component that it is on top of show through.
in addition to what Paul said, there's the question if you use self made components.
Such components should take care of their complete occupied region (or at least the invalidated regions) in the paint callback. An error seen quite often that leads to strange artifacts when moving or resizing is that only "important" parts are repainted, for example a string to be shown, without drawing the background.
In this case, anything previously blitted ther will show through.
I'm trying to modify an existing application using AWT for dialogs, etc. I don't know all the code of the application, so I'm not sure how are the objects stacked.
I tried adding a new JButton to a JPanel with no layout. I set location and size, validated, repainted... and nothing is displayed. Now I'm a bit lost - how do I figure out why this happened? Is there some way to poke around a live application window and see the AWT objects tree? How do I approach this kind of problems?
Disclaimer: I know next to nothing about AWT.
Logging! Making log calls whenever you're manipulating anything on the AWT stack. Most (all?) AWT objects also have decent toString methods, so it's possible to get and print objects in a component and get meaningful debugging information (i.e. for(Component c : frame.getComponents()) { System.err.println(c.toString()); } ).