| Summary: | mouse cursor lacks transparency in High Sierra (macOS 10.13) | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Mark Kim <libsdl> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | icculus, incredible.angst, josh+sdl, kanjitalk755, sezeroz |
| Version: | 1.2.15 | Keywords: | target-2.0.12 |
| Hardware: | x86_64 | ||
| OS: | macOS 10.13 | ||
| Attachments: |
Example code and resulting screenshots on macOS 10.12 vs. 10.13
Patch extracted from https://github.com/kanjitalk755/SDL/tree/forHighSierra Patch extracted from https://github.com/kanjitalk755/SDL/tree/forHighSierra - trailing newline fix |
||
|
Description
Mark Kim
2018-02-11 13:39:47 UTC
To be fair, nobody actually pointed the finger at SDL in that MacPorts ticket; in fact it seems more likely be an OS bug. To fix this bug, please refer to the following repo. https://github.com/kanjitalk755/SDL/tree/forHighSierra Is this the fix? https://github.com/kanjitalk755/SDL/commit/0296d5e601a5deb5ce2f540a8eafd64dd22dbe69 Only SDL_QuartzWM.m is directly involved in fixing this bug. SDL_QuartzVideo.h was fixed in Bug2085. Others are fixes for building with the latest XQuartz. I confirm kanjitalk755's github branch fixes the issue. Thank you! Steps taken to confirm the fix: 0. Requirements: Tux Paint 0.9.23rc dated 2017-12-24 (the test application), MacPorts with the packages required by Tux Paint installed from source (required by Tux Paint). 1. Download libsdl forHighSierra branch from github as a .zip file. 2. Build the libsdl forHighSierra branch: Unzip the file, ./autogen.sh && ./configure --prefix=/opt/local && make && sudo make install. (The --prefix=/opt/local option is required by MacPorts) 3. Build the Tux Paint application: make && make install 4. Run TuxPaint.app The resulting application runs as expected in all observable aspects (sound, graphics, mouse clicks, typing, etc.) The mouse cursor is displayed as expected, with no background inversion issue previously reported. The test application was built on macOS 10.12, with its output executable tested on both macOS 10.12 and 10.13. Has this been merged into the main SDL repo? Marking fixed is a bit premature if not. Reopening. Created attachment 3720 [details] Patch extracted from https://github.com/kanjitalk755/SDL/tree/forHighSierra Extracted from https://github.com/kanjitalk755/SDL/tree/forHighSierra, commit https://github.com/kanjitalk755/SDL/commit/0296d5e601a5deb5ce2f540a8eafd64dd22dbe69 mentioned here in discussion. Fixes problem for me on Mac OS 10.13 (High Sierra), not tried on other versions. Created attachment 3721 [details] Patch extracted from https://github.com/kanjitalk755/SDL/tree/forHighSierra - trailing newline fix (Sorry if you get several emails like this, we're marking a bunch of bugs.) We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle. Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release. If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug. --ryan. This patch was applied in https://hg.libsdl.org/SDL/rev/0cfa2cc751eb ... resolving this bug! --ryan. We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc). As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change! Thanks, --ryan. |