Quantcast

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

Sergey Bylokhov
(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:



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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 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:[hidden email]] On Behalf Of Patrick Chen
Sent: maandag 10 april 2017 12:23
To: [hidden email]
Subject: Re: <Swing Dev> JDK-8178091 : Bug I will workin on

 

(edit : for example this game coded in java : 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 <[hidden email]>:

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

 

 

 








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

Patrick Chen
so here a webrev : 

2017-04-12 23:41 GMT+02:00 Sergey Bylokhov <[hidden email]>:
(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:



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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 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:[hidden email]] On Behalf Of Patrick Chen
Sent: maandag 10 april 2017 12:23
To: [hidden email]
Subject: Re: <Swing Dev> JDK-8178091 : Bug I will workin on

 

(edit : for example this game coded in java : 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 <[hidden email]>:

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

 

 

 









Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

Patrick Chen

2017-04-17 12:33 GMT+02:00 Patrick Chen <[hidden email]>:
so here a webrev : 

2017-04-12 23:41 GMT+02:00 Sergey Bylokhov <[hidden email]>:
(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:



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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 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:[hidden email]] On Behalf Of Patrick Chen
Sent: maandag 10 april 2017 12:23
To: [hidden email]
Subject: Re: <Swing Dev> JDK-8178091 : Bug I will workin on

 

(edit : for example this game coded in java : 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 <[hidden email]>:

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

 

 

 










Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

Philip Race
Per openjdk rules, we cannot review or accept webrevs hosted anywhere
other than 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

On 4/17/17, 3:42 AM, Patrick Chen wrote:

2017-04-17 12:33 GMT+02:00 Patrick Chen <[hidden email]>:
so here a webrev : 

2017-04-12 23:41 GMT+02:00 Sergey Bylokhov <[hidden email]>:
(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:



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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 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:[hidden email]] On Behalf Of Patrick Chen
Sent: maandag 10 april 2017 12:23
To: [hidden email]
Subject: Re: <Swing Dev> JDK-8178091 : Bug I will workin on

 

(edit : for example this game coded in java : 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 <[hidden email]>:

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

 

 

 










Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

Philip Race


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 , 


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 <[hidden email]>:
Per openjdk rules, we cannot review or accept webrevs hosted anywhere
other than 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


On 4/17/17, 3:42 AM, Patrick Chen wrote:

2017-04-17 12:33 GMT+02:00 Patrick Chen <[hidden email]>:
so here a webrev : 

2017-04-12 23:41 GMT+02:00 Sergey Bylokhov <[hidden email]>:
(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:



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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 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:[hidden email]] On Behalf Of Patrick Chen
Sent: maandag 10 april 2017 12:23
To: [hidden email]
Subject: Re: <Swing Dev> JDK-8178091 : Bug I will workin on

 

(edit : for example this game coded in java : 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 <[hidden email]>:

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

 

 

 












Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

Patrick Chen
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 <[hidden email]>:


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 , 


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 <[hidden email]>:
Per openjdk rules, we cannot review or accept webrevs hosted anywhere
other than 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


On 4/17/17, 3:42 AM, Patrick Chen wrote:

2017-04-17 12:33 GMT+02:00 Patrick Chen <[hidden email]>:
so here a webrev : 

2017-04-12 23:41 GMT+02:00 Sergey Bylokhov <[hidden email]>:
(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:



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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 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:[hidden email]] On Behalf Of Patrick Chen
Sent: maandag 10 april 2017 12:23
To: [hidden email]
Subject: Re: <Swing Dev> JDK-8178091 : Bug I will workin on

 

(edit : for example this game coded in java : 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 <[hidden email]>:

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

 

 

 













Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

Patrick Chen
edit : So (sorry if I repeat myseft )

what I propose : 


bug :  JDK-8178091

2017-04-20 11:37 GMT+02:00 Patrick Chen <[hidden email]>:
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 <[hidden email]>:


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 , 


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 <[hidden email]>:
Per openjdk rules, we cannot review or accept webrevs hosted anywhere
other than 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


On 4/17/17, 3:42 AM, Patrick Chen wrote:

2017-04-17 12:33 GMT+02:00 Patrick Chen <[hidden email]>:
so here a webrev : 

2017-04-12 23:41 GMT+02:00 Sergey Bylokhov <[hidden email]>:
(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:



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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 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:[hidden email]] On Behalf Of Patrick Chen
Sent: maandag 10 april 2017 12:23
To: [hidden email]
Subject: Re: <Swing Dev> JDK-8178091 : Bug I will workin on

 

(edit : for example this game coded in java : 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 <[hidden email]>:

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

 

 

 














Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

Philip Race
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 : 


bug :  JDK-8178091

2017-04-20 11:37 GMT+02:00 Patrick Chen <[hidden email]>:
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 <[hidden email]>:


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 , 


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 <[hidden email]>:
Per openjdk rules, we cannot review or accept webrevs hosted anywhere
other than 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


On 4/17/17, 3:42 AM, Patrick Chen wrote:

2017-04-17 12:33 GMT+02:00 Patrick Chen <[hidden email]>:
so here a webrev : 

2017-04-12 23:41 GMT+02:00 Sergey Bylokhov <[hidden email]>:
(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:



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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 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:[hidden email]] On Behalf Of Patrick Chen
Sent: maandag 10 april 2017 12:23
To: [hidden email]
Subject: Re: <Swing Dev> JDK-8178091 : Bug I will workin on

 

(edit : for example this game coded in java : 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 <[hidden email]>:

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

 

 

 














Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <Swing Dev> JDK-8178091 : Bug I will workin on

Prahalad kumar Narayanan
In reply to this post by Sergey Bylokhov
Hello Pat

I 'm not comfortable adding this check for os.name in a common code.
It breaks the very foundation of having os specific code organized in different folders.

From the inference that 've got from this mail chain, I believe, the issue appears to be from rendering pipeline (linux).
So identifying the root cause and fixing it in respective pipeline would be better a better approach.

Thanks
Have a good day

Prahalad N.

----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Apr 2017 14:40:40 +0200
From: Patrick Chen <[hidden email]>
To: Phil Race <[hidden email]>
Cc: 2d-dev <[hidden email]>, "[hidden email]"
        <[hidden email]>
Subject: Re: [OpenJDK 2D-Dev] <Swing Dev> JDK-8178091 : Bug I will
        workin on
Message-ID:
        <CANmuJ8vUdpVx00O7C39idMywQFc7AdaA=[hidden email]>
Content-Type: text/plain; charset="utf-8"

edit : So (sorry if I repeat myseft )

what I propose :

webrev :
http://cr.openjdk.java.net/~alexsch/chen.j.patrick/8178091/webrev.01/

bug :  JDK-8178091

2017-04-20 11:37 GMT+02:00 Patrick Chen <[hidden email]>:

> 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 <[hidden email]>:
>
>>
>>
>> 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 ,
>>
>>
>> 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 <[hidden email]>:
>>
>>> Per openjdk rules, we cannot review or accept webrevs hosted
>>> anywhere other than 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
>>>
>>>
>>> On 4/17/17, 3:42 AM, Patrick Chen wrote:
>>>
>>> https://github.com/cloudStrif/webrev
>>>
>>>
>>> 2017-04-17 12:33 GMT+02:00 Patrick Chen <[hidden email]>:
>>>
>>>> so here a webrev :
>>>>
>>>> 2017-04-12 23:41 GMT+02:00 Sergey Bylokhov
>>>> <[hidden email]>
>>>> :
>>>>
>>>>> (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
>>>>>
>>>>>
>>>>>
>>>>> 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 <[hidden email]>:
>>>>>
>>>>>> 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 <
>>>>>> [hidden email]>:
>>>>>>
>>>>>>>
>>>>>>> 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 <
>>>>>>> [hidden email]>:
>>>>>>>
>>>>>>>> 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 <[hidden email]>:
>>>>>>>>
>>>>>>>>> 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-j
>>>>>>>>> ava-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:[hidden email]]
>>>>>>>>> *On Behalf Of *Patrick Chen
>>>>>>>>> *Sent:* maandag 10 april 2017 12:23
>>>>>>>>> *To:* [hidden email]
>>>>>>>>> *Subject:* Re: <Swing Dev> JDK-8178091 : Bug I will workin on
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (edit : for example this game coded in java :
>>>>>>>>> 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
>>>>>>>>> <[hidden email]
>>>>>>>>> >:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170420/7ff24d9c/attachment.html>

End of 2d-dev Digest, Vol 119, Issue 11
***************************************
Loading...