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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Sep 8 10:57:54 UTC 2015


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.



More information about the swing-dev mailing list