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