If appropriate conceptually (and I am not sure it is), then this
is better addressed in a more localised way in code specific to
the xrender pipeline which is the only pipeline that has this
problem .. correct ? And if it is only in this pipeline an investigation
into the specifics of what is different would be the place to start.
-phil.
On 4/20/17, 5:40 AM, Patrick Chen wrote:
edit : So (sorry if I repeat myseft )
what I propose :
webrev :
http://cr.openjdk.java.net/~alexsch/chen.j.patrick/8178091/webrev.01/
<http://cr.openjdk.java.net/%7Ealexsch/chen.j.patrick/8178091/webrev.01/>
bug : JDK-8178091
2017-04-20 11:37 GMT+02:00 Patrick Chen <chen.j.patr...@gmail.com
<mailto:chen.j.patr...@gmail.com>>:
Hi ,
thank you Alexandr !
You are right Phil , but for the moment I did a lot of tests , and
it seems that there is no problems with this method ...
so as the bug is only on Linux I check on the method if we are on
linux or not , then only I sync() ,
like this , on other system ,it will use the asynchrone repaint()
method ,
I think for the moment it is a possible way to correct the
JDK-8178091 bug ,
of course , it is maybe not final ,
but it works well.
-Pat
2017-04-19 18:27 GMT+02:00 Phil Race <philip.r...@oracle.com
<mailto:philip.r...@oracle.com>>:
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
