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

Thu Sep 10 10:12:09 UTC 2015

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?

>
> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

-- 
Best regards, Sergey.