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

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Fri Sep 25 09:13:53 UTC 2015


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/25/2015 9:26 AM, prasanta sadhukhan wrote:
> Added null check for SwingUtilities.getUnwrappedParent(table).
> Please review the updated webrev
> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.08/
>
> Regards
> Prasanta
> On 9/24/2015 5:19 PM, Alexander Scherbatiy wrote:
>> On 9/23/2015 12:26 PM, prasanta sadhukhan wrote:
>>>
>>>
>>> On 9/23/2015 2:46 PM, Alexander Scherbatiy wrote:
>>>> On 9/23/2015 9:42 AM, prasanta sadhukhan wrote:
>>>>> I have updated the code as per your comment.
>>>>> Please review this webrev
>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.07/
>>>>
>>>>    - Is it possible that SwingUtilities.getUnwrappedParent(table) 
>>>> returns null?
>>> I have not seen it. It will return at least JRootPane, I guess.
>>
>>    Is it possible just crate a JTable with some rows and print it, 
>> without adding to a frame or some others components?
>>
>>    Thanks,
>>    Alexandr.
>>>>    - Does the fix work correctly for a case when rMax has initial 
>>>> zero value but it is decremented on line 1857?
>>> rMax can have -1 from table.rowAtPoint() in which case it will be 
>>> changed to total rowCount so it will not be 0 before line 1857.
>>>
>>> Regards
>>> Prasanta
>>>>
>>>>   Thanks,
>>>>   Alexandr.
>>>>
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 9/22/2015 7:01 PM, Alexander Scherbatiy wrote:
>>>>>> On 9/21/2015 12:05 PM, prasanta sadhukhan wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 9/21/2015 2:20 PM, Alexandr Scherbatiy wrote:
>>>>>>>> 18.09.2015 10:16, prasanta sadhukhan пишет:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/17/2015 8:18 PM, Alexander Scherbatiy wrote:
>>>>>>>>>> On 9/16/2015 2:04 PM, prasanta sadhukhan wrote:
>>>>>>>>>>> Hi Alexander, Sergey,
>>>>>>>>>>>
>>>>>>>>>>> Waiting for your review on this.
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.06/
>>>>>>>>>>
>>>>>>>>>>    Could you describe why the paint artifacts are drawn when 
>>>>>>>>>> a scroll pane is present?
>>>>>>>>> I see that normally JTable has always been associated with 
>>>>>>>>> JScrollpane and it uses
>>>>>>>>> // Paint the grid.
>>>>>>>>>  paintGrid(g, rMin, rMax, cMin, cMax);
>>>>>>>>> // Paint the cells.
>>>>>>>>> paintCells(g, rMin, rMax, cMin, cMax);
>>>>>>>>> to paint the cells in the table.
>>>>>>>>> When we scroll the table, rMin can be say 41 and rMax can be 
>>>>>>>>> 43 so it expects to draw 3 rows with the above code (since the 
>>>>>>>>> for loop uses rows = rMin; rows <= rMax)
>>>>>>>>> Also, sometimes rMin canbe 44 and rMax can be 44 too in which 
>>>>>>>>> case 1 row would be painted as per the above for loop
>>>>>>>>>
>>>>>>>>> but since I have modified the code to use (to make same rows 
>>>>>>>>> to show on console and in printed page)
>>>>>>>>>
>>>>>>>>> // Paint the grid.
>>>>>>>>>  paintGrid(g, rMin, rMax-1, cMin, cMax);
>>>>>>>>> // Paint the cells.
>>>>>>>>> paintCells(g, rMin, rMax-1, cMin, cMax);
>>>>>>>>>
>>>>>>>>> it paints only 2 rows (or 0 rows in case rMin=rMax=44 where 
>>>>>>>>> rMax-1 is 43 so for loop will not be executed) and when we go 
>>>>>>>>> on scrolling, 1 less row gets painted always than what it 
>>>>>>>>> expects resulting in artifacts.
>>>>>>>>> So, I have kept the same code for JTable when it has 
>>>>>>>>> scrollpane (which was till now the case)
>>>>>>>>
>>>>>>>>     - Does it mean if the initialpaintGrid()/Cell() methods are 
>>>>>>>> used there are artifacts when a table is not used with 
>>>>>>>> JScrollPane?
>>>>>>> When table is not used with JScrollPane, there is no change of 
>>>>>>> table visible rows (since user is not scrolling the table) so 
>>>>>>> there is no artifacts if table does not have jscrollpane.
>>>>>>>>     - It is not necessary to add isScrollPanePresent varibale 
>>>>>>>> if it is used only once
>>>>>>> I did not understand. It's a variable and not a function. So, 
>>>>>>> what you are proposing me to do?
>>>>>>
>>>>>>
>>>>>> It is possible just to use
>>>>>> -----------------------------
>>>>>> +        if (some expression) {
>>>>>>                // do something
>>>>>>           }
>>>>>> -----------------------------
>>>>>> instead of
>>>>>> -----------------------------
>>>>>> +        boolean isScrollPanePresent = true;
>>>>>> +        if (some expression) {
>>>>>> +            isScrollPanePresent = false;
>>>>>> +        }
>>>>>> +        if (isScrollPanePresent) {
>>>>>>                // do something
>>>>>>           }
>>>>>> -----------------------------
>>>>>>
>>>>>>  In your case it is even better just to update the rMax according 
>>>>>> to is scroll pane presence.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>    Alexandr.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>>>
>>>>>>>>>>    Thanks,
>>>>>>>>>>    Alexandr.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> On 9/15/2015 10:55 AM, prasanta sadhukhan wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/14/2015 12:48 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/11/2015 2:20 PM, prasanta sadhukhan wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review which takes care of this configuration
>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.06/
>>>>>>>>>>>> Gentle reminder for review request.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>




More information about the swing-dev mailing list