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 <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>: > >> >> >> 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 <philip.r...@oracle.com>: >> >>> 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 <chen.j.patr...@gmail.com>: >>> >>>> so here a webrev : >>>> >>>> 2017-04-12 23:41 GMT+02:00 Sergey Bylokhov <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 >>>>> >>>>> >>>>> >>>>> 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>: >>>>> >>>>>> 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>: >>>>>> >>>>>>> >>>>>>> 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>: >>>>>>> >>>>>>>> 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>: >>>>>>>> >>>>>>>>> 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:swing-dev-boun...@openjdk.java.net] *On >>>>>>>>> Behalf Of *Patrick Chen >>>>>>>>> *Sent:* maandag 10 april 2017 12:23 >>>>>>>>> *To:* 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 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 >>>>>>>>> >: >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> >
