8303904: Transparent Windows Paint Wrong (Opaque) w/o Volatile Buffering

[mickleness]

The original write-up contains two complaints:

1. The window is opaque, so pixels that should be transparent are black.
2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated).

I recommend splitting this up into separate tickets.

This PR addresses the first (probably most offensive) issue: the window is now transparent.

I experimented with a change that resolves the second issue (image resolution) here:
90735b7

... that works, but IMO that looks riskier and should be part of a separate discussion.

I only have a Mac configured right now to test against, so I've confirmed the MTLGraphicsConfig and CGLGraphicsConfig changes. The other GraphicsConfig changes are identical, but I haven't confirmed that this new test passes in those environments. (I did confirm that those GraphicsConfig files appear to support getColorModel(Transparency.TRANSLUCENT), so I'm optimistic they'll be OK.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Integration blocker

 ⚠️ Title mismatch between PR and JBS for issue JDK-8303904

Issue

• JDK-8303904: [macos]Transparent Windows Paint Wrong (Opaque, Pixelated) w/o Volatile Buffering ⚠️ Title mismatch between PR and JBS.

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13196/head:pull/13196
$ git checkout pull/13196

Update a local copy of the PR:
$ git checkout pull/13196
$ git pull https://git.openjdk.org/jdk.git pull/13196/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13196

View PR using the GUI difftool:
$ git pr show -t 13196

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13196.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mickleness! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@mickleness The following label will be automatically applied to this pull request:

• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (ffc8ff44)
• 00: Full (4284d4cd)

[mlbridge]

Mailing list message from Alan Snyder on client-libs-dev:

When I added support for translucent windows to VAqua, I used a different solution: I ?tricked? the AWT Window into
accepting a transparent (alpha = 0) background color. I?m not sure if this is better or worse than your idea of suppressing the
painting of the background, but it does raise the issue of why AWT Windows insist on the background color being
opaque. Would something break if that restriction were removed? Using a transparent background color does not seem
to cause any problems on macOS and it seems like a natural way for a developer to indicate the desire to have
a window with a transparent or translucent background.

[mickleness]

Alan, I may be confused. Does VAqua rely on turning off volatile buffering?

Or your comment might (?) make more sense if it's for my other PR (for 8303950) that relates to this method:

jdk/src/java.desktop/share/classes/java/awt/Window.java

Lines 3946 to 3960 in a8871f5

	public void paint(Graphics g) {
	if (!isOpaque()) {
	Graphics gg = g.create();
	try {
	if (gg instanceof Graphics2D) {
	gg.setColor(getBackground());
	((Graphics2D)gg).setComposite(AlphaComposite.getInstance(AlphaComposite.SRC));
	gg.fillRect(0, 0, getWidth(), getHeight());
	}
	} finally {
	gg.dispose();
	}
	}
	super.paint(g);
	}

(Also: thanks for mentioning VAqua! I'll check it out. I was a big fan of Werner's Quaqua work a decade ago at another job.)

[mlbridge]

Mailing list message from Alan Snyder on client-libs-dev:

I may be confused, too! I haven?t kept close track of the various issues and PRs.

My comment relates to a perhaps old idea of using a graphics rendering hint to suppress painting the window background.

VAqua knows nothing about volatile buffering, nor do I. :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230407/0f51a235/attachment-0001.htm>

[bridgekeeper]

@mickleness This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper]

@mickleness This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

[mickleness]

What is the fate of auto-closed PRs?

That is: as long as I don't delete this branch in my repo will this be available for future reference if anyone dusts off this ticket in the future?