<Swing Dev> RFR: [9] [JDK-8081491] The case print incomplete.

Fri Sep 11 08:50:11 UTC 2015


On 9/10/2015 4:48 PM, Sergey Bylokhov wrote:
> On 10.09.15 13:35, prasanta sadhukhan wrote:
>>
>>
>> On 9/10/2015 3:42 PM, Sergey Bylokhov wrote:
>>> On 10.09.15 9:36, prasanta sadhukhan wrote:
>>>> Please review the modified webrev which solves this artifacts.
>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.05/
>>>
>>> What will happen if the table will be added to the jpanel and the
>>> jpanel will be added to JScrollPane? Will this configuration work as
>>> expected?
>>>
>>>>
>>>> I also added a reg test for this regression but I am not able to 
>>>> create
>>>> a automated testcase to deal with the scrolling artifacts, so I 
>>>> added a
>>>> manual test.
>>>
>>> I suggest to try to automate it somehow. Probably make some small
>>> unity test? Or using robot?
>> Even with Robot or unity test, how will I check the artifact has
>> happened? THis is a visual problem. I do not know how to test it
>> automatically.
>
> In case of unit test you can check the return value of some methods or 
> the state of the objects which are cause the artifacts. For test with 
> robot, you can fill all rows of table in some color, then scroll it, 
> and check the color of the table using robot.getPixelColor().
Thanks Sergey for the suggestion. I am trying to use Robot to test this 
artifacts. But when I use Robot to scroll up/down, the artifacts are not 
seen even when the scrollbar moved up and down. But manually if I 
scroll, I can see the artifacts. Can you please let me know if the 
attached testcase is missing something?

Regards
Prasanta
>
>>
>> --Prasanta
>>>
>>>>
>>>> Regards
>>>> Prasanta
>>>> On 9/8/2015 4:27 PM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Just before the push of this fix I made small pit, and found a
>>>>> regression. Please run the SwingSet2, open JTable demo, and scroll 
>>>>> the
>>>>> table. You will see some artifacts.
>>>>>
>>>>> On 08.09.15 13:13, prasanta sadhukhan wrote:
>>>>>> Thanks Sergey for pointing this.
>>>>>> I have taken care of this plus formatting in for loop.
>>>>>> Please have a look
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.04/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 9/8/2015 3:32 PM, Sergey Bylokhov wrote:
>>>>>>> Hi, Prasanta.
>>>>>>> A few small notes:
>>>>>>>  - BasicTableUI: typo "1850 // otherwise 1 extra rows are ptinted"
>>>>>>>  - ImageableAreaTest: the test instructions have copy pasted 
>>>>>>> numbers
>>>>>>> 1/2/2/2 etc.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 08.09.15 12:43, prasanta sadhukhan wrote:
>>>>>>>> Thanks for your review.
>>>>>>>>   I need +1 for this. Alexander Z/Sergey, can you please approve
>>>>>>>> this
>>>>>>>> fix?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 9/8/2015 3:02 PM, Alexander Scherbatiy wrote:
>>>>>>>>>
>>>>>>>>>   The fix looks good to me.
>>>>>>>>>
>>>>>>>>>   But you need to properly format spaces in the 'for' loop on 
>>>>>>>>> line
>>>>>>>>> TablePrintable:410 before the push.
>>>>>>>>>
>>>>>>>>>   Thanks,
>>>>>>>>>   Alexandr.
>>>>>>>>>
>>>>>>>>> On 9/8/2015 12:26 PM, prasanta sadhukhan wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/7/2015 5:50 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 9/7/2015 9:23 AM, prasanta sadhukhan wrote:
>>>>>>>>>>>> I guess it will be same but anyways have modified to use
>>>>>>>>>>>> visibleBounds.getLocation() to be on safeside as we are 
>>>>>>>>>>>> dealing
>>>>>>>>>>>> with visible region for this fix.
>>>>>>>>>>>> Please review the updated webrev
>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.02/
>>>>>>>>>>>
>>>>>>>>>>>     TablePrintable:
>>>>>>>>>>>      - Could the rMin be equal to -1?
>>>>>>>>>> This should never happen so long bounds intersects the clip 
>>>>>>>>>> but as
>>>>>>>>>> done in BasicTableUI, I have added the check just in case
>>>>>>>>>>> - Line: 406  int rowHeight = (rMax-rMin) * 
>>>>>>>>>>> table.getRowHeight();
>>>>>>>>>>>        Rows can have different height in the table. Could you
>>>>>>>>>>> also
>>>>>>>>>>> add a test for the this case too?
>>>>>>>>>>>
>>>>>>>>>> Added test for this case too.
>>>>>>>>>> Please review this webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.03/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>>>> Thanks,
>>>>>>>>>>>     Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Prasanta
>>>>>>>>>>>> On 9/4/2015 8:57 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Could the clip.getLocation() be differ from them
>>>>>>>>>>>>> visibleBounds.getLocation()?
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Thanks,
>>>>>>>>>>>>>  Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/4/2015 3:32 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>>>> Any reviewers for this please?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/2/2015 5:06 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can this fix be reviewed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>>> On 8/28/2015 4:48 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 8/26/2015 6:24 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>> On 8/25/2015 1:51 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 8/25/2015 3:53 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>> On 8/24/2015 2:23 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081491
>>>>>>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.00/ 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This seems to be a hidden JTable bug in which if the
>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>> does not call pack() or set a ScrollPane() for JTable
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> rather use JFrame.setSize() smaller than table size
>>>>>>>>>>>>>>>>>>>> then it
>>>>>>>>>>>>>>>>>>>> was found that some of the rows which cannot be
>>>>>>>>>>>>>>>>>>>> fitted in
>>>>>>>>>>>>>>>>>>>> 1st page cannot get printed on 2nd and subsequent 
>>>>>>>>>>>>>>>>>>>> pages
>>>>>>>>>>>>>>>>>>>> resulting in blank cells to be printed after 1st page.
>>>>>>>>>>>>>>>>>>>> It was found that BasicTableUI checks for table
>>>>>>>>>>>>>>>>>>>> bounds to
>>>>>>>>>>>>>>>>>>>> fall within the clip and if they do not intersect, it
>>>>>>>>>>>>>>>>>>>> bails
>>>>>>>>>>>>>>>>>>>> out from painting the table cells.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      What is the reason that the graphics clip does not
>>>>>>>>>>>>>>>>>>> intersect the table bounds during printing in the
>>>>>>>>>>>>>>>>>>> provided
>>>>>>>>>>>>>>>>>>> test case?
>>>>>>>>>>>>>>>>>> The testcase does table.setSize(600,800) whereas frame
>>>>>>>>>>>>>>>>>> setSize is 400,600 .
>>>>>>>>>>>>>>>>>> For 1st page, the clip was 0,0,384,752 and bounds was
>>>>>>>>>>>>>>>>>> 0,0,384,562 so they intersect and there's no problem in
>>>>>>>>>>>>>>>>>> printing the rows in 1st page.
>>>>>>>>>>>>>>>>>> After the 1st page is printed, the clip is set to
>>>>>>>>>>>>>>>>>> 0,752,384,48 since we have printed the rows that we can
>>>>>>>>>>>>>>>>>> fit
>>>>>>>>>>>>>>>>>> in 1st page and the next set of rows are to be printed
>>>>>>>>>>>>>>>>>> while
>>>>>>>>>>>>>>>>>> bounds remains at 0,0,384,562 because JComponent
>>>>>>>>>>>>>>>>>> getBounds is
>>>>>>>>>>>>>>>>>> returning the visible frame bounds which did not change.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     The !bounds.intersects(clip) check prevents 
>>>>>>>>>>>>>>>>> printing of
>>>>>>>>>>>>>>>>> table rows which are not visible on the frame.
>>>>>>>>>>>>>>>>>     It seems that the issue is that extra rows which are
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> shown in the frame are printed on the first page.
>>>>>>>>>>>>>>>>>     It means that the printed rows and columns should be
>>>>>>>>>>>>>>>>> calculated for the table bounds and clip intersection.
>>>>>>>>>>>>>>>>>     The test can be updated to mention that only visible
>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>> of the table should be printed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Have modified the code to print only the rows that are
>>>>>>>>>>>>>>>> displayed on console. Also updated the test to mention the
>>>>>>>>>>>>>>>> same. Please review the updated webrev.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.01/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please, also mention in the email title JDK version for
>>>>>>>>>>>>>>>>>>> which the fix is provided.
>>>>>>>>>>>>>>>>>> Done
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I devised a solution whereby it will not bail out till
>>>>>>>>>>>>>>>>>>>> either rows or columns are still left to be printed on
>>>>>>>>>>>>>>>>>>>> subsequent pages . Please review and let me know if
>>>>>>>>>>>>>>>>>>>> it's ok.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: JTableScrollTest.java
Type: text/x-java
Size: 5561 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150911/7d6d8d83/JTableScrollTest.java>