[OpenJDK 2D-Dev] <Swing Dev> JDK-8178091 : Bug I will workin on
Patrick Chen
chen.j.patrick at gmail.com
Thu Apr 20 12:40:40 UTC 2017
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.patrick at 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.race at 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.race at 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.patrick at gmail.com>:
>>>
>>>> so here a webrev :
>>>>
>>>> 2017-04-12 23:41 GMT+02:00 Sergey Bylokhov <sergey.bylokhov at 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.patrick at 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.bylokhov at 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.bylokhov at 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 <WLaan at 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-bounces at openjdk.java.net] *On
>>>>>>>>> Behalf Of *Patrick Chen
>>>>>>>>> *Sent:* maandag 10 april 2017 12:23
>>>>>>>>> *To:* swing-dev at 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.patrick at 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170420/7ff24d9c/attachment.html>
More information about the 2d-dev
mailing list