> When "swing.volatileImageBufferEnabled" is false: we were mistakenly using an > opaque image at 100% resolution. > > In hindsight the original ticket probably should be split up into two > distinct issues: > 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). > > This PR started 2 years ago. I got stuck and abandoned it, and @anass-baya > picked it back up again this year: https://github.com/openjdk/jdk/pull/23430/ > > In that PR @mrserb suggested we try to fix this problem in RepaintManager > (see https://github.com/openjdk/jdk/pull/23430#discussion_r2089555453 ), so > that's what this PR does. > > Also this refactors some existing code (the BackingStoreMultiResolutionImage) > from JViewport to wrap a BufferedImage in a smaller (transformed) > MultiResolutionImage.
Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision: - Merge branch 'master' into JDK-8303904 - Merge branch 'master' into JDK-8303904 - 8303904: comment cleanup - 8303904: designing around imagined edge cases I don't know if these will ever come up in the real world, but since this is critical infrastructure I want to be careful. (A Swing app may become unusable if this code fails.) Concern A: In the event our AffineTransform is a rotation or a flip: Now we'll use the c.createImage(virtualWidth, virtualHeight), which means we fall back to the code we've been using for over a decade. Concern B: In the event our AffineTransform scales to zero, we'll at least make the image 1x1. - 8303904: minor cleanup - 8303904: minor cleanup - 8303904: minor cleanup This makes this method ALWAYS return a BackingStoreMultiResolutionImage, even if the scaled size is the same as the virtual size. (Just because making this method return a BufferedImage OR a BackingStoreMultiResolutionImage seems like an unnecessary level of abstraction; and that could turn into a potential point of confusion for future devs.) - 8303904: use BackingStoreMultiResolutionImage It's functionally the same thing; this is just reusing code (and it avoids the hacky fake image involving getScaledInstance). - Revert "8303904: support rotated GraphicsConfiguration" This reverts commit 55b1a708cdc8608824d04974ad96b62fd50149d3. - Revert "8303904: fixing AffineTransform fields" This reverts commit 2d32aaf0e670a9967877e5a4bf4c0ec1079bb070. - ... and 22 more: https://git.openjdk.org/jdk/compare/a80eb2b8...a3eb2d62 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13196/files - new: https://git.openjdk.org/jdk/pull/13196/files/ee0d8b1e..a3eb2d62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13196&range=02-03 Stats: 605872 lines in 6705 files changed: 415549 ins; 120902 del; 69421 mod Patch: https://git.openjdk.org/jdk/pull/13196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13196/head:pull/13196 PR: https://git.openjdk.org/jdk/pull/13196
