beattidp
asked on
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?
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?
I got the same problem on MSWindows2000 with all the service packs and JAVA 2 1.4.2_05 !
;JOOP!
;JOOP!
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!
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!
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.
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.
>> Is this a JAVA bug?
I hate to think of that.
I hate to think of that.
> its known as show contents while dragging feature in windows
dragging and resizing are two different things...
dragging and resizing are two different things...
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?
Well, that would be only resizing ;-) that's how you resize it. Dragging would be 'holding the component and moving it'.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I found what seems to be causing this; the method:
JFrame.setDefaultLookAndFe
... 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 'setDefaultLookAndFeelDeco
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.setContinuousLay
.... 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?
JFrame.setDefaultLookAndFe
... 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 'setDefaultLookAndFeelDeco
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.setContinuousLay
.... 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?
I think there is something wrong with your code.
Did you try the example i gave you?
Does the setDefaultLookAndFeelDecor
Did you try the example i gave you?
Does the setDefaultLookAndFeelDecor
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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/
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/
I was already convinced.
;JOOP!
;JOOP!
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
''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
I think the CPU usage never was a problem, just the flickering.
;JOOP!
;JOOP!
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 "DefaultLookAndFeelDecorat
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, "DefaultLookAndFeelDecorat
> 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.
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 "DefaultLookAndFeelDecorat
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, "DefaultLookAndFeelDecorat
> 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.
Well, I almost agree, but don't underestimate the priorities a customer may have.
;JOOP!
;JOOP!
OK.
;JOOP!
;JOOP!
:°)
This should be OS and VM dependent.
By the way, what are your OS and JRE version?