pointerup pressure should always be 0 #146

Closed
appsforartists opened this Issue Sep 20, 2016 · 10 comments

Comments

Projects
None yet
4 participants
@appsforartists

appsforartists commented Sep 20, 2016

pointerup is defined to be when a {finger,stylus} loses contact with the screen or when mouse buttons are no longer being pushed. Therefore, I'd expect the pressure value of every pointerup event to be 0. Moreover, the spec requires pressure to be 0 if the hardware doesn't support it and no buttons are active (that is, the pointer is up).

Maddeningly, its actual value is different across implementations. Here's the current breakdown:

Platform Browser Pointer pointerup pressure is 0 pointerup pressure is whatever the last pointermove recorded
Android Chrome touch ☑️
iOS Safari via PEP touch ☑️
Mac Chrome trackpad ☑️
Mac Chrome Wacom stylus ☑️
Mac Chrome Wacom touch ☑️ (always 1, spec says it should be .5)
Mac Firefox trackpad ☑️
Mac Firefox Wacom stylus ☑️
Mac Firefox Wacom touch ☑️
Mac Safari via PEP trackpad ☑️
Mac Safari via PEP Wacom stylus ☑️
Mac Safari via PEP Wacom touch ☑️
ChromeOS Chrome touch ☑️
ChromeOS Chrome trackpad ☑️
Windows Chrome or Edge touch ☑️
Windows Chrome or Edge trackpad ☑️
Windows Chrome or Edge stylus ☑️
Windows Firefox touch ☑️
Windows Firefox trackpad ☑️
Windows Firefox stylus ☑️

And here's the test. If the background turns green on pointerup, pressure is 0. If it turns red, pressure is using a stale value from pointermove.

tl;dr:

  • Firefox always sets pressure to 0 in pointerup.
  • The other desktop browsers use 0 for stylus and trackpad, but the last pointermove value for touch.
  • iOS and Android both use the last pressure value from pointermove.

Can we please explicitly declare in the spec that pressure should be 0 in every pointerup? This would be consistent with the currently specified behavior for pointers that don't granularly report pressure.

Here are the relevant bugs:

@NavidZ

This comment has been minimized.

Show comment
Hide comment
@NavidZ

NavidZ Sep 20, 2016

Member

Thanks for the complete analysis. I'm going to work on the Chrome bug and will take care of that. It does seem that the pressure 0 for pointerup might be good to added as Note in the spec. I wonder what others think about it.

Member

NavidZ commented Sep 20, 2016

Thanks for the complete analysis. I'm going to work on the Chrome bug and will take care of that. It does seem that the pressure 0 for pointerup might be good to added as Note in the spec. I wonder what others think about it.

@mustaqahmed

This comment has been minimized.

Show comment
Hide comment
@mustaqahmed

mustaqahmed Sep 21, 2016

Contributor

The definition of pressure in the spec seems to have another crack here:

For hardware that does not support pressure, the value must be 0.5 when in the active buttons state and 0 otherwise.

So in this case, a hovering barrel button press on a stylus would report a pressure of 0.5, which seems counter-intuitive. Same is true for a stylus that is flipped to eraser mode, see #134.

So instead of adding a Note, I prefer fixing the definition .

Contributor

mustaqahmed commented Sep 21, 2016

The definition of pressure in the spec seems to have another crack here:

For hardware that does not support pressure, the value must be 0.5 when in the active buttons state and 0 otherwise.

So in this case, a hovering barrel button press on a stylus would report a pressure of 0.5, which seems counter-intuitive. Same is true for a stylus that is flipped to eraser mode, see #134.

So instead of adding a Note, I prefer fixing the definition .

@NavidZ

This comment has been minimized.

Show comment
Hide comment
@NavidZ

NavidZ Sep 21, 2016

Member

Posting Dave Fleck's reply to github:

I would recommend that a stylus without pressure should report 1.0 not 0.5. The thinking goes like this:

In an application I choose a line width. If I draw with a mouse this is the width that will be drawn.

With a pressure stylus I will draw a percentage of that width (assuming pressure modulates width not opacity or some other characteristic) up to full pressure = full width.

A non-pressure stylus should act like a mouse and draw full width, not 50% with a non-pressure stylus, up to 100% with a pressure stylus, and 100% with a mouse.

Member

NavidZ commented Sep 21, 2016

Posting Dave Fleck's reply to github:

I would recommend that a stylus without pressure should report 1.0 not 0.5. The thinking goes like this:

In an application I choose a line width. If I draw with a mouse this is the width that will be drawn.

With a pressure stylus I will draw a percentage of that width (assuming pressure modulates width not opacity or some other characteristic) up to full pressure = full width.

A non-pressure stylus should act like a mouse and draw full width, not 50% with a non-pressure stylus, up to 100% with a pressure stylus, and 100% with a mouse.

@NavidZ

This comment has been minimized.

Show comment
Hide comment
@NavidZ

NavidZ Sep 21, 2016

Member

With that reasoning I have the feeling that it should be 1 for mouse or any other device that doesn't pressure either. Because as the handler you just check for the pointermove and draw it. Why would you care about whether pointerType was pen or mouse? Anybody knows why it was 0.5 in the first place?

Member

NavidZ commented Sep 21, 2016

With that reasoning I have the feeling that it should be 1 for mouse or any other device that doesn't pressure either. Because as the handler you just check for the pointermove and draw it. Why would you care about whether pointerType was pen or mouse? Anybody knows why it was 0.5 in the first place?

@appsforartists

This comment has been minimized.

Show comment
Hide comment
@appsforartists

appsforartists Sep 21, 2016

aside: It's really confusing that there are e-mail threads and GitHub issues discussing the same thing. I keep seeing "Posting Dave Fleck's reply to GitHub" messages. It would be great if he would just comment here himself.


I didn't have anything to do with the current spec, but I suspect the motivation is that 1 is pressing really hard with a tablet, where .5 is closer to the amount of pressure someone would normally apply. If you change the default to 1, you're either going to end up with really thin lines when a pointer supports pressure or really thick lines when it doesn't.

To test this hypothesis, I used my Wacom Intuos in Firefox and a Surface Book in Chrome. In both cases, normal strokes reported a pressure around .3-.5. 1 is pressing pretty hard.

Thinking as engineers, it's tempting to make it binary: 1 is down and 0 is off. However, I suspect applications that actually care about pressure will work better with .5 - it's closer to the amount of pressure someone would probably be applying if the pointer reported it correctly.

appsforartists commented Sep 21, 2016

aside: It's really confusing that there are e-mail threads and GitHub issues discussing the same thing. I keep seeing "Posting Dave Fleck's reply to GitHub" messages. It would be great if he would just comment here himself.


I didn't have anything to do with the current spec, but I suspect the motivation is that 1 is pressing really hard with a tablet, where .5 is closer to the amount of pressure someone would normally apply. If you change the default to 1, you're either going to end up with really thin lines when a pointer supports pressure or really thick lines when it doesn't.

To test this hypothesis, I used my Wacom Intuos in Firefox and a Surface Book in Chrome. In both cases, normal strokes reported a pressure around .3-.5. 1 is pressing pretty hard.

Thinking as engineers, it's tempting to make it binary: 1 is down and 0 is off. However, I suspect applications that actually care about pressure will work better with .5 - it's closer to the amount of pressure someone would probably be applying if the pointer reported it correctly.

@dfleck

This comment has been minimized.

Show comment
Hide comment
@dfleck

dfleck Sep 21, 2016

aside aside: Sorry - I don't quite know the protocol here. Hopefully I got it right now?

Some users have a soft touch and some have a heavy touch. To accomodate this the hardware needs to be able to handle a heavy touch (you can make it softer in software, but you can't make it heavier if you don't have the range to sense it). A control panel is provided to make the touch lighter for those with a lighter touch. If you have a soft touch you should adjust it in the tablet control panel so that t is adjusted everywhere (even including how hard to press to register a click).

Using 0.5 results in a mismatch between Pointer Evenets and all other applications/situations. Desktop apps will use 100% as will non-Pointer Event web apps. Only Pointer Event web apps. will be limited to 50%

Instead of pressure modulates width, lets take pressure modulates opacity as an example. A mouse will draw 100% dark line. A pressure stylus will draw a 0% to 100% dark line. But a non-pressure stylus will only ever draw 50% dark line? How do I draw a dark line with a non-pressure stylus? It's not like I can set the app. to draw lines at 200% darkness to compensate.

As an engineer, when I see 0.00 to 1.00 I tend to think in percentages from none to full. If the resolution is lower I simply scale the values. With two bits of resolution I'd do 0%, 33%, 66% and 100%. If I'm going to drop the resolution to a single bit, I tend to think none and full, not none and half, so I would do 0% and 100% not 0% and 50%. But maybe that's just me.

dfleck commented Sep 21, 2016

aside aside: Sorry - I don't quite know the protocol here. Hopefully I got it right now?

Some users have a soft touch and some have a heavy touch. To accomodate this the hardware needs to be able to handle a heavy touch (you can make it softer in software, but you can't make it heavier if you don't have the range to sense it). A control panel is provided to make the touch lighter for those with a lighter touch. If you have a soft touch you should adjust it in the tablet control panel so that t is adjusted everywhere (even including how hard to press to register a click).

Using 0.5 results in a mismatch between Pointer Evenets and all other applications/situations. Desktop apps will use 100% as will non-Pointer Event web apps. Only Pointer Event web apps. will be limited to 50%

Instead of pressure modulates width, lets take pressure modulates opacity as an example. A mouse will draw 100% dark line. A pressure stylus will draw a 0% to 100% dark line. But a non-pressure stylus will only ever draw 50% dark line? How do I draw a dark line with a non-pressure stylus? It's not like I can set the app. to draw lines at 200% darkness to compensate.

As an engineer, when I see 0.00 to 1.00 I tend to think in percentages from none to full. If the resolution is lower I simply scale the values. With two bits of resolution I'd do 0%, 33%, 66% and 100%. If I'm going to drop the resolution to a single bit, I tend to think none and full, not none and half, so I would do 0% and 100% not 0% and 50%. But maybe that's just me.

@appsforartists

This comment has been minimized.

Show comment
Hide comment
@appsforartists

appsforartists Sep 21, 2016

@dfleck Thanks for commenting here! 😃

I broke this thread out into #147 to avoid distracting from the pointerup issue

appsforartists commented Sep 21, 2016

@dfleck Thanks for commenting here! 😃

I broke this thread out into #147 to avoid distracting from the pointerup issue

@appsforartists

This comment has been minimized.

Show comment
Hide comment
@appsforartists

appsforartists Sep 22, 2016

I've written tests asserting that pointerup has 0 pressure:

web-platform-tests/wpt#3794

I've written tests asserting that pointerup has 0 pressure:

web-platform-tests/wpt#3794

@appsforartists appsforartists referenced this issue in web-platform-tests/wpt Sep 27, 2016

Merged

Assert pressure is 0 during pointerup #3794

RByers added a commit to web-platform-tests/wpt that referenced this issue Sep 28, 2016

[pointerevents] Assert pressure is 0 during pointerup (#3794)
* Remove dead code in iframe

* Set event.buttons to match event.pressure
One of these tests asserts that pressure is settable.  In a real implementation, pressure shouldn't be set unless buttons is also set.  Therefore, the test should also set buttons, to test a realistic state.

* Add constructor tests for event.button and event.buttons

* Assert event.pressure is 0 when event.type == pointerup
This enforces w3c/pointerevents#146
@NavidZ

This comment has been minimized.

Show comment
Hide comment
@NavidZ

NavidZ Oct 20, 2016

Member

This issue seems to be easy to fix. Aside from Chrome bug, is everybody okay with having 0 for pointerup? I wonder if we need to explicitly call it out in the spec or would the exiting text imply this clearly enough?

Member

NavidZ commented Oct 20, 2016

This issue seems to be easy to fix. Aside from Chrome bug, is everybody okay with having 0 for pointerup? I wonder if we need to explicitly call it out in the spec or would the exiting text imply this clearly enough?

@NavidZ NavidZ added the v2-blocking label Oct 20, 2016

@dfleck

This comment has been minimized.

Show comment
Hide comment
@dfleck

dfleck Oct 20, 2016

Yes! Zero pressure during pointerup. It wouldn't hurt to make this clearer in the spec.

dfleck commented Oct 20, 2016

Yes! Zero pressure during pointerup. It wouldn't hurt to make this clearer in the spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment