On 04/19/2017 12:51 AM, Patrick Chen wrote:
Ok so can you take the source from the git ?
Sounds the same to me as reviewing it there ..
You probably have an account in cr.openjdk.java.net
<http://cr.openjdk.java.net/> ,
but Another solution to fix the bug 8178091 is to write a repaint()
method from Component.java
(as we all know : JPanel.java -->(extends) >Jcomponent.java
-->(extends)-> Composent.java)
and the repaint() method is on Component.java
So in JPanel.java we add a method repaint() ;
public void repaint(){
super.repaint() ; //this call repaint() from Component.java to
reproduce a simple repaint();
Toolkit.getDefaultToolkit().sync();
}
sync sounds to me more like adding a performance problem rather than
fixing one.
I'd be very reluctant to accept such a change in core JDK without
appropriate
performance testing across all affected pipelines and platforms.
And I don't think it is correct anyway. repaint is asynchronous and trying
to make it synchronous is redefining it 20 years too late.
But if you do it yourself in your own code that is up to you ...
-phil.
so with this each time we call repaint() ; it call our new repaint()
method with the sync();
and then it works well
2017-04-17 16:24 GMT+02:00 Philip Race <philip.r...@oracle.com
<mailto:philip.r...@oracle.com>>:
Per openjdk rules, we cannot review or accept webrevs hosted anywhere
other than cr.openjdk.java.net <http://cr.openjdk.java.net> [1]
Generally you ask someone who has a login there to do it for you
Or you may try submitting the patch in-line to this email if it is
short.
Not an attachment. It will get stripped.
-phil.
[1] http://openjdk.java.net/guide/changePlanning.html
<http://openjdk.java.net/guide/changePlanning.html>
On 4/17/17, 3:42 AM, Patrick Chen wrote:
https://github.com/cloudStrif/webrev
<https://github.com/cloudStrif/webrev>
2017-04-17 12:33 GMT+02:00 Patrick Chen <chen.j.patr...@gmail.com
<mailto:chen.j.patr...@gmail.com>>:
so here a webrev :
2017-04-12 23:41 GMT+02:00 Sergey Bylokhov
<sergey.bylok...@oracle.com <mailto:sergey.bylok...@oracle.com>>:
(CC) 2d-dev
If some of these options helps then most probably the bug
is in the Java2D pipeline(XRender?) and looks like this
is duplicate of:
https://bugs.openjdk.java.net/browse/JDK-8068529
<https://bugs.openjdk.java.net/browse/JDK-8068529>
OK ,
So I did severals tests with theses options with
programms using full repaint() method
,and it still work well,
but occasionnaly ,the lag is here again ,particularly
when there are a lot component on the screen (Jpanel screen)
indeed , I think it is not normal that we need theses
options to work well ,
but it seem the problem does not come from Swing package
, but repaint() method in AWT package ,
2017-04-12 21:26 GMT+02:00 Patrick Chen
<chen.j.patr...@gmail.com
<mailto:chen.j.patr...@gmail.com>>:
OK ,
So I did severals tests with theses options with
programms using full repaint() method
,and it still work well,
but occasionnaly ,the lag is here again
,particularly when there are a lot component on the
screen (Jpanel screen)
indeed , I think it is not normal that we need
theses options to work well ,
but it seem the problem does not come from Swing
package , but repaint() method in AWT package ,
2017-04-11 19:18 GMT+02:00 Sergey Bylokhov
<sergey.bylok...@oracle.com
<mailto:sergey.bylok...@oracle.com>>:
Hi ,
yes ;
with theses options it works !
but what that means ?
Is it works in case of any options or in some
cases it does not work? Please double check.
so it not a bug ?
2017-04-11 18:46 GMT+02:00 Sergey Bylokhov
<sergey.bylok...@oracle.com
<mailto:sergey.bylok...@oracle.com>>:
Hi, Patrick.
Can you please run the code using these
options:
-Dsun.java2d.xrender=true
-Dsun.java2d.xrender=false
-Dsun.java2d.opengl=true
-Dsun.java2d.opengl=false
After tests it seems that the problem
doesn't come from Timer , but
the repaint() method ,
even with this code the bug is here.
the bug is on Linux.
2017-04-11 11:07 GMT+02:00 Walter Laan
<wl...@costengineering.eu
<mailto:wl...@costengineering.eu>>:
Note that the example code in
JDK-8178091 sleeps on the EDT, so
you’re lucky it paints at all instead
of hanging the UI.
It looks like you adapted the code
from
http://codereview.stackexchange.com/questions/29630/simple-java-animation-with-swing
<http://codereview.stackexchange.com/questions/29630/simple-java-animation-with-swing>
where no-one experienced with Swing
pointed out this error L.
Using a javax.swing.Timer (not the
java.util.Timer!) and it runs okay
(using Win10, Java 8u101):
*private**void*go() {
*new*Timer(10, *new*ActionListener() {
// _Les_ _coordonnées_ _de_ _départ_
_de_ _notre_ _rond_
*private**int*x= pan.getPosX(), y=
pan.getPosY();
// _Le_ _booléen_ pour _savoir_ _si_
l'on _recule_ _ou_ non _sur_ l'axe x
*private**boolean*backX= *false*;
// _Le_ _booléen_ pour _savoir_ _si_
l'on _recule_ _ou_ non _sur_ l'axe y
*private**boolean*backY= *false*;
@Override
*public**void*actionPerformed(ActionEvent
e) {
// _Si_ _la_ _coordonnée_ x est
_inférieure_ à 1, on _avance_
*if*(x< 1) {
backX= *false*;
}
// _Si_ _la_ _coordonnée_ x est
_supérieure_ à _la_ _taille_ _du_
_Panneau_ _moins_ _la_ _taille_ _du_
_rond_, on _recule_
*if*(x> pan.getWidth() - 50) {
backX= *true*;
}
// _Idem_ pour l'axe y
*if*(y< 1) {
backY= *false*;
}
*if*(y> pan.getHeight() - 50) {
backY= *true*;
}
// _Si_ on _avance_, on _incrémente_
_la_ _coordonnée_
// backX est _un_ _booléen_, _donc_
!backX _revient_ à _écrire_
// if (backX == false)
*if*(!backX) {
pan.setPosX(++x);
// _Sinon_, on _décrémente_
}
*else*{
pan.setPosX(--x);
}
// _Idem_ pour l'axe Y
*if*(!backY) {
pan.setPosY(++y);
}
*else*{
pan.setPosY(--y);
}
// On _redessine_ _notre_ _Panneau_
pan.repaint();
}
}).start();
}
Hope that helps,
Walter.
*From:*swing-dev
[mailto:swing-dev-boun...@openjdk.java.net
<mailto:swing-dev-boun...@openjdk.java.net>]
*On Behalf Of *Patrick Chen
*Sent:* maandag 10 april 2017 12:23
*To:* swing-...@openjdk.java.net
<mailto:swing-...@openjdk.java.net>
*Subject:* Re: <Swing Dev> JDK-8178091
: Bug I will workin on
(edit : for example this game coded in
java :
https://github.com/cloudStrif/GoldenSunD
<https://github.com/cloudStrif/GoldenSunD>
will work with java 7
but clearly not with java8 (linux 64
bits) because of lags)
2017-04-10 12:19 GMT+02:00 Patrick
Chen <chen.j.patr...@gmail.com
<mailto:chen.j.patr...@gmail.com>>:
Hi every one ,
just wanted to inform that I am
working to fix this bug.
it is when we devellop animations
thanks to repaint() method ,
for java 7 it works well
but with java8 not ,
(linux 64 bits it doesn't really
work )
so after watching the source code
it seem that it is not a swing
problem
but AWT : Component.java .
thank you
