• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2150
  • Last Modified:

Disable perpetual repaint during resizing of JFrame?

Ugly perpetual repaint as I re-size a JFrame.  This is CPU-intensive, and
would probably make Swing look really ugly on slower systems.

When re-sizing, the user should see only an outline of the extending edge(s),
and the frame would snap and re-paint only when the edge is dropped.

( I'm not entirely clear as to what constitutes a resize, but from the looks of it,
 I wouldn't be surprised if a resize event occurs for every pixel moved.)

I have seen an incomplete and sparse example (i.e. non-working solution)
elsewhere in EE, which uses addComponentListener to override the
componentResized, but I fear that would do the same thing, since it re-paints
every time the frame is "re-sized."   A also tried adding a component listener,
with an empty function for componentResized, but observed no change in behavior.
 
 - Is this more complex than it seems?

          (Perhaps inhibit re-paint until the edge of the component is dropped?)

 - Or is there a magic attribute that would fix this instantly?

0
beattidp
Asked:
beattidp
  • 7
  • 7
  • 2
  • +2
2 Solutions
 
GrandSchtroumpfCommented:
I have never encountered such problem
This should be OS and VM dependent.
By the way, what are your OS and JRE version?
0
 
sciuriwareCommented:
I got the same problem on MSWindows2000 with all the service packs and JAVA 2 1.4.2_05 !

;JOOP!
0
 
sciuriwareCommented:
I did some research: the phenomenon shows when the L&F is METAL in other words: JAVA standard look-and-feel.
This is very unpleasant as this L&F is more than mandatory when an application must run on various OS's
in the same environment, so people can get used to the appearance.
Is this a JAVA bug?

;JOOP!
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
JohnnyAffaCommented:
beattidp,

i think youre talking about show contents while dragging feature on windowX platforms and not a java bug/ugly feature.

lemme get this straight, when you start your app and then resize the frame, the contents is shown while you resize huh? (its known as show contents while dragging feature in windows, and as luck would have it, you can disable it).

on windows98SE, right click desktop/select features, untick "show contents while dragging".....and thats it! no more ugly repainting.

on other windowsX, it should be something similar

as for linux, i cant remember, but shouldnt be to hard to find


note: this is platform specific feature and not a java one.
0
 
Mayank SAssociate Director - Product EngineeringCommented:
>> Is this a JAVA bug?

I hate to think of that.
0
 
GrandSchtroumpfCommented:
> its known as show contents while dragging feature in windows
dragging and resizing are two different things...
0
 
JohnnyAffaCommented:
Grand, when i mean drag im mean move mouse pointer over frame border, pressing and holding mouse button, then using the mouse, "DRAGGING" it to resize a frame, which is the same as resizing no?
0
 
Mayank SAssociate Director - Product EngineeringCommented:
Well, that would be only resizing ;-) that's how you resize it. Dragging would be 'holding the component and moving it'.
0
 
GrandSchtroumpfCommented:
JohnnyAffa,
In XP, it's called "show windows contents while dragging" (Display Props/Appearance/Effect...).
I have just tested it.
When unchecked, it also has the effect of not calling repaint when a window is resized untill the mouse button is released...
This means you are right...  unchecking it should solve the problem.
But it will change the behaviour of all Windows.

beattidp,
Do you call or override any of these methods in your code: paint, repaint, update?
Do you have the same behaviour with all your JFrames for all java applications or is it just a problem with one specific app?

Try a simple JPanel inside a JFrame:

class JPanelTest {
  public static void main(String[] args) {
    javax.swing.JFrame myFrame = new javax.swing.JFrame("Test");
    javax.swing.JPanel myPanel = new javax.swing.JPanel();
    myPanel.setBackground(java.awt.Color.RED);
    myFrame.setBackground(java.awt.Color.BLUE);
    myFrame.getContentPane().add(myPanel);
    myFrame.setSize(new java.awt.Dimension(200,200));
    myFrame.setVisible(true);
  }
}

Can you see any blue when you resize your frame?
0
 
beattidpAuthor Commented:
I found what seems to be causing this; the method:

   JFrame.setDefaultLookAndFeelDecorated(true);

 ... this will cause the perpetual re-paint during re-size,  in
Windows XP, anyway.

I know that in Windows XP, there are Desktop options to disable
refresh while re-sizing; in other words, you see only an outline
of the extending edge(s),  and the frame snaps and re-paints
only when the edge is dropped -- I do have this option enabled.
Using JFrame method 'setDefaultLookAndFeelDecorated(true)'
seems to override this, causing a continuous re-paint while resizing.

I removed that from my code, and the JFrame behaves as I wish.
However, I also discovered that there is a method to do this directly
for a JSplitPane:

     splitPane.setContinuousLayout(false);

.... turns off continuous re-paint during re-size of the split pane. So,
where is the analogue/equivalent for JFrame, which would override
the decorated Look-and-Feel ?

I don't know about the JRE on platforms other than Windows XP, but
why should I need to keep the decorated Look-and-Feel disabled,
just to inhibit the perpetual repaint?  Is this an idiosyncrasy which will
be a problem when running on different platforms, or can I guarantee
consistency in some way, so there is a never a re-paint during re-size?
0
 
GrandSchtroumpfCommented:
I think there is something wrong with your code.
Did you try the example i gave you?
Does the setDefaultLookAndFeelDecorated(true/false) change the way the repaint is done?
0
 
sciuriwareCommented:
Some people may have mis-read my last post: both look&feels were on the same platform (W2K)
and the native one did not suffer from this problem.
The only difference between the applications was the call:

     JFrame.setDefaultLookAndFeelDecorated(true);

which independently was discovered to be the cause by 'beattidp' him/her-self.
This call is necessary to give an application a METAL look from the start (even the frame itself),
       and to make it pixel-equal to the view on UNIX, LINUX and OSX (e.g.)

So afterall this is a bug in JAVA!
I suggest we enter this together in the JAVA bugreport:

                  http://bugs.sun.com/bugdatabase/index.jsp

to make it count as severe.

;JOOP!

P.S.: sorry, no points this time!
0
 
beattidpAuthor Commented:
I first noticed this when running the ''Split-Pane Demo'' from Java Web Start:

  http://java.sun.com/docs/books/tutorialJWS/uiswing/components/example-1dot4/SplitPaneDemo.jnlp

Perhaps you can see how it runs on your system -- try to re-size the frame...
There are plenty of examples there, but I haven't tested more of them.
http://java.sun.com/docs/books/tutorial/uiswing/components/example-1dot4/

And sorry for the anonymity -- I'm a hardware engineer, trying to leverage the
power of Java, initially for internal R&D use.

--
Douglas Beattie Jr. . . .http://www.hytherion.com/beattidp/
0
 
sciuriwareCommented:
I was already convinced.
;JOOP!
0
 
GrandSchtroumpfCommented:
i don't have the problem (build 1.4.2_01-b06).
''Split-Pane Demo'' does not seem to use more CPU than any other window when it is resized.
I'm just getting an annoying flickering, that's all.

> sorry for the anonymity
there's nothing wrong with wanting to stay anonymous
0
 
sciuriwareCommented:
I think the CPU usage never was a problem, just the flickering.

;JOOP!
0
 
GrandSchtroumpfCommented:
If it's only the flickering that you are worried about, i'm pretty sure SUN already knows that.
Even when you uncheck "show windows contents while dragging", you still get the flickering.
I guess this has to do with the fact that the JFrame must paint over the OS's window borders... so there might be no other choice than using a perpetual repaint.

For the CPU-intensive issue, you should not worry about it.

If you don't want the flickering, just use an OS-decorated JFrame.
I don't really see why you would want to use the "DefaultLookAndFeelDecorated".
It has no real advantages... you get a uniform look across different platforms, but you lose uniformity accross applications on your OS...  and i like all my windows to look the same.
And as you can see it has some drawbacks, such as the flickering... i'm currious to know if there is a platform on which it does not flicker.
Also, "DefaultLookAndFeelDecorated", as its name suggests it, only works with the Metal PLAF.

>  So afterall this is a bug in JAVA!
I dont think it's a bug, but a small annoyance if you absolutely want to have a metal-looking frame.
0
 
sciuriwareCommented:
Well, I almost agree, but don't underestimate the priorities a customer may have.
;JOOP!
0
 
sciuriwareCommented:
OK.
;JOOP!
0
 
GrandSchtroumpfCommented:
:°)
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 7
  • 7
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now