If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Need HiDPI versions of our custom OS X cursors

RESOLVED FIXED in mozilla18

Status

()

Core
Widget: Cocoa
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Dolske, Assigned: Dolske)

Tracking

unspecified
mozilla18
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Assignee)

Description

5 years ago
Filing a separate bug for the artwork-specific piece of bug 784909...

We ship a number of custom mouse cursors/pointers in Gecko, since CSS specs a number of standard cursors for which OS X has no system equivalent:

http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/cursors/

(I just landed bug 789849, which makes us use .png instead of .tiff for these.)

The immediate goal is to make double-res versions of these, so that these don't look blurry on OS X on retina displays. The existing icons are also kind of... ugly... so any beautification would be welcome.

Demo of cursors: http://dolske.net/mozilla/tests/hidpi/cursors.html

A few extra notes:
* Cursors can be any size, but the HiDPI versions must be exactly 2x the resolution of the base pointer.
* 32bit PNG (RGBA) is fine, partial transparency should work fine.
* The default "hotspot" (the specific pixel that the cursor operates upon) defaults to the upper-left, but can be adjusted to any point. See:
  https://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsCursorManager.mm#72

Oh, and there's one animated cursor... We animate it manually, so adjusting the framecount / delay should be easy.
(In reply to Justin Dolske [:Dolske] from comment #0)
> We ship a number of custom mouse cursors/pointers in Gecko, since CSS specs
> a number of standard cursors for which OS X has no system equivalent:
> 
> http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/cursors/

So, I was doing some investigation before I started making these. It looks like Mountain Lion ships retina capable cursors for all of these cases. You can see them at: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Resources/cursors

In some cases they have a 1x bitmap version, but all of them appear to have a resolution independent PDF version. There is a corresponding info.plist that defines the shadow.

I am pretty sure Safari is using these. Any reason we can't just use the system cursor?
Created attachment 665746 [details]
HiDPI Cursors - i01

Updated all of the cursors we currently use to be more in line with the OS X versions. Except the Help cursor, I didn't like that one so I deviated ;)

Also added Move and Cell cursors. The only one I didn't update was the Wait cursor still thinking about that.

I increased the size to 24x24 for the 1x cursors to accommodate the shadow. 48x48 for the 2x versions. Probably need to test them to make sure positioning and stuff is correct.
(Assignee)

Comment 3

5 years ago
Created attachment 665823 [details] [diff] [review]
Patch v.1

Cursors from attachment 665746 [details], in patch form.

* Adjusted hotspot pixels in the code to match up with new images (generally +4,+4 but I tweaked a few specially)
* Changed code to use our  custom "move" and "cell" cursors, to match what Safari/Chrome are using.
Assignee: shorlander → dolske
(Assignee)

Comment 4

5 years ago
(In reply to Stephen Horlander from comment #1)
> [...]
> I am pretty sure Safari is using these. Any reason we can't just use the
> system cursor?

Already replied on IRC, but FTR:

Some of this info is already in bug 784909, but I hadn't figured out that the info.plist was giving the PDF images shadows. Haven't tested, but I'll assume this actually works if we feed the system PDFs to the API we're using here.

However, there are a couple of catches. Mainly, it would be fair for Apple to move these files at any time, so loading them directly would be prone to breakage. It's kind of dumb they haven't just made them available through the normal nsCursor API, but whatever. As a minor point, I suspect these files don't exist on pre-OSX-10.7.3, so we'd need to retain the current code anyway until we drop 10.6 support.
(Assignee)

Updated

5 years ago
Whiteboard: [leave open]
(Assignee)

Comment 5

5 years ago
Comment on attachment 665823 [details] [diff] [review]
Patch v.1

Flagging for post-landing review. Steven wanted to try these out in a live environment. Given the low impact of breaking this stuff, let's just do that in Nightly.
Attachment #665823 - Flags: ui-review?(shorlander)

Comment 6

5 years ago
https://hg.mozilla.org/mozilla-central/rev/a3b635cad2d8
Comment on attachment 665823 [details] [diff] [review]
Patch v.1

The hidpi cursors work. We need to file a followup bug about getting the right cursor displaying. Sometimes the platform cursor is showing which is outdated/incorrect. 

n-resize, e-resize, s-resize, w-resize are showing the platform arrow with a bar which is wrong. ew-resize and ns-resize are showing the double-sided arrows with a bar which is for col/row resize.
Attachment #665823 - Flags: ui-review?(shorlander) → ui-review+
(Assignee)

Comment 8

5 years ago
Filed bug 800232 for making *-resize match Chrome/Safari.

Also filed bug 800233 for updating our still-clunky progress/wait cursor.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [leave open]
(Assignee)

Updated

5 years ago
Target Milestone: --- → mozilla18
You need to log in before you can comment on or make changes to this bug.