pointerup pressure should always be 0 #146
Comments
|
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. |
|
The definition of pressure in the spec seems to have another crack here:
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 . |
|
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. |
|
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? |
|
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. |
|
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. |
|
I've written tests asserting that |
* 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
|
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? |
|
Yes! Zero pressure during pointerup. It wouldn't hurt to make this clearer in the spec. |
pointerupis 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 everypointerupevent 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:
And here's the test. If the background turns green on
pointerup,pressureis 0. If it turns red,pressureis using a stale value frompointermove.tl;dr:
pointerup.pointermovevalue for touch.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:
The text was updated successfully, but these errors were encountered: