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

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

Closed
wants to merge 15 commits into from

Conversation

mickleness
Copy link
Contributor

@mickleness mickleness commented Mar 27, 2023

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

mickleness and others added 14 commits May 22, 2022 04:50
Merge openjdk/jdk into mickleness/jdk
Updating mickleness/jdk from openjdk/jdk
…es image

This is part of the original write-up, but it might deserve to be split up into its own ticket.
I predict once I start a code review about 8308904 that if we want to address the resolution of createAcceleratedImage: that can be a separate ticket. This change feels much more invasive to me; I wouldn't be surprised if some existing code out there is already casting the return value of createAcceleratedImage(..) as a BufferedImage.
I started to notice some intermittent failures in the Robot test, so now I'm having it wait a few beats on the event dispatch thread before grabbing the pixel color.

Also I'm adding a more abstract check-the-translucency-of-the-BufferedImage output. If this `testImageTransparency` passes and `testPixelColor` fails: that's a red flag that maybe the screen isn't ready when the Robot grabs the pixel.
This is the same solution previously applied to the MTLGraphicsConfig
I don't have my setup configured to test these, but I confirmed they all appear to support translucency in their getColorModel(int) method.
@bridgekeeper
Copy link

bridgekeeper bot commented Mar 27, 2023

👋 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 openjdk bot added the rfr Pull request is ready for review label Mar 27, 2023
@openjdk
Copy link

openjdk bot commented Mar 27, 2023

@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.

@openjdk openjdk bot added the client client-libs-dev@openjdk.org label Mar 27, 2023
@mlbridge
Copy link

mlbridge bot commented Mar 27, 2023

Webrevs

@mlbridge
Copy link

mlbridge bot commented Apr 7, 2023

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
Copy link
Contributor Author

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:

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
Copy link

mlbridge bot commented Apr 8, 2023

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>

mrserb recommended against this in a separate PR

openjdk#13408 (comment)
@bridgekeeper
Copy link

bridgekeeper bot commented May 9, 2023

@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
Copy link

bridgekeeper bot commented Jun 6, 2023

@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.

@bridgekeeper bridgekeeper bot closed this Jun 6, 2023
@mickleness
Copy link
Contributor Author

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?

@aivanov-jdk
Copy link
Member

What is the fate of auto-closed PRs?

@mickleness You can reopen the PR with the /open command.

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?

If you keep the branch in your repo, you or anyone could use it as the base to continue working on this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client client-libs-dev@openjdk.org rfr Pull request is ready for review
2 participants