<Swing Dev> RFR: [9] [JDK-8081491] The case print incomplete.
prasanta sadhukhan
prasanta.sadhukhan at oracle.com
Thu Sep 10 10:35:48 UTC 2015
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.
--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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
More information about the swing-dev
mailing list