Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unstable table grid line width with 125% scale on Windows #152

Open
electriq opened this issue Aug 4, 2020 · 5 comments
Open

Unstable table grid line width with 125% scale on Windows #152

electriq opened this issue Aug 4, 2020 · 5 comments
Milestone

Comments

@electriq
Copy link

electriq commented Aug 4, 2020

Hi! I found that if the scale ('font size') is set to 125% (common on 15" FullHD laptop; Windows 10), the table grid is drawn with 1 or 2 pixel line depending on current position of the table inside the scroll pane. Sometomes some lines are 1 px and some 2 px. It also switching haotically while moving an internal frame with a table in it.

The only difference between these two screenshots is scrolling the table down. The horizintal lines become 2 px from 1 px. Vertical line are 1 and 2 px:

Table1
Table2

@DevCharly
Copy link
Collaborator

Yes, this is a common problem with painting in Java on scaled displays.
You never know whether a line becomes 1px or 2px thick (without anti-aliasing).

Window LaF and Metal have the same problems.
On the other hand, Nimbus and Substance do not have this problem.

FlatLaf currently uses BasicTableUI for painting the table. Unfortunately all painting methods in BasicTableUI are private and it is not possible to change/improve something without re-implementing the whole table painting in FlatTableUI.

I tried to use anti-aliasing, which looks better, but the grid lines are too thick IMHO (125%; Java 14):

image

And with anti-aliasing the selection has gaps if grid lines are disabled, which is the default:

image

Grid lines are disabled, but anti-aliasing causes gaps between cells:

image

Probably have to re-implement table painting in FlatTableUI to fix this.
But this takes time...

For now I would recommend to use a lighter color for the grid lines. Then it is harder to notice 😉

If you want try anti-aliasing yourself, add following to FlatTableUI:

@Override
public void paint( Graphics g, JComponent c ) {
	FlatUIUtils.setRenderingHints( (Graphics2D) g );
	super.paint( g, c );
}

@DevCharly
Copy link
Collaborator

Fixed in commit 5ef0c9a

It turned out that the fix for https://bugs.openjdk.java.net/browse/JDK-8133919
in commit openjdk/jdk@803735d
is the reason for the unstable grid line width. (since Java 9)

BasicTableUI.paintGrid() now uses Graphics.fillRect() instead of drawLine() for painting grid lines.

Nimbus does not have unstable grid line width because it has a copy of paintGrid(), which still uses drawLine().

@DevCharly DevCharly added this to the 0.45 milestone Nov 28, 2020
@electriq
Copy link
Author

electriq commented Dec 5, 2020

With this patch (I did't tested before your release, sorry) I see unstable grid over the selection (background/grid color). And we have lost the right border of the custom row header which is a simple one-column JTable which does not draw the last vertical line now (maybe this is not a bug if last vertical line is not specifyed in docs, I don't know -- it just worked before).

2020-12-05_203410 2020-12-05_203136

@DevCharly
Copy link
Collaborator

Ah, now I see it too. That's probably because the lines are now thinner than the space between the cells...
Need to fix cell bounds too. Have to investigate whether this is possible...

The fix for #46 is the reason for the missing right border of the row header...

@DevCharly DevCharly reopened this Dec 5, 2020
@electriq
Copy link
Author

electriq commented Dec 5, 2020

OK, fixing our row header border was simple :)

    rowHeader = new JTable(rowTableModel)
    {
      @Override
      protected void paintComponent(Graphics g)
      {
        super.paintComponent(g);
        
        g.setColor(table.getGridColor());
        g.drawLine(getWidth() - 1, 0, getWidth() - 1, getHeight());
      }
    };

It seems you and us will end up with paintComponent() 'overloading' every pixel of Swing's default UI :)))
Thank you for your work!

DevCharly added a commit that referenced this issue Dec 12, 2020
…g table as row header in scroll pane (issues #152 and #46)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants