How about tablet pen properties (pen pressure, tilt, etc) with onmousemove event?

Hi there.

well, I want to add a draw in canvas more effective. with pen tablets, or portable tablet with pen.

then, these pen infomation into onmousemove event.

Let’s see how it works with pseudo code.

canvas.onmousemove = function(e){
    if(e.penSupport){ // is your browser have a pen or pen event support?
        console.log('pen pressure : ' + e.pen.pressure);
        console.log('pen tilt : ' + ['x : ', e.pen.tiltX, 'y : ', e.pen.tiltY].join(','));

I think it’s more useful for drawing, pen note, signing, etc.

is it too small suggest?

1 Like

To get these additional bits (pressure, tilt, etc), you would need Pointer Events.


What’s the status on pointer events in non-IE browsers, BTW? I thought MS was submitting patches? Are they not being accepted?

1 Like

I think it’s not need this feature because pen tablet industry is not standard and they are only support windows and mac. not linux. no standard, company-specific… ONLY FOR CG ARTISTS. web browser is not for specific bodies.

It can just figure it out with plugins. no more needs.

Linux does get tablet support. Just not directly from the vendors. Search for “digimend” or “linuxwacom”.

(I do recall that linuxwacom did have a full time Wacom employee as a contributor, not sure if that’s still the case.)

I would have to disagree with this. I know plenty of non-designers that use a stylus for pointer accuracy on touch devices and things like taking written notes. The Nintendo DS is a good example on how stylus are used by more than just CG artists.

Personally I think it would be better to extend TouchEvent than MouseEvent for this. I’ve got some thoughts in the context of Chrome Android here:

It seems really ugly to extend Touch or Mouse events for Pen input. Especially adding things like Tilt (x, y) along with various other things that will probably come in the future (eraser?). Also, since pen can be used with the other two inputs (mouse is less likely, but touch is definitely a use case), it needs to be decoupled from them.

Ideally Pointer Events is the right answer to all this, but Google is having fun using their market share like IE did in the past to go forward pushing legacy functions that we would be best to deprecate now.

Either way, this needs to be very low level and tested heavily with the canvas for speed as it is the most practical application.

1 Like

Here’s an example of this working with pointer events in IE and a Wacom Intous 5 pen tablet:



event.pressure //ranges 0-1
event.tiltX //ranges -90 to 90, represents angle "left/right" from a line normal with the screen
event.tiltY //ranges -90 to 90, represents angle "forward/back" from a line normal with the screen

This should be supported in the Firefox branch where pointer events development is happening (planned to be ported to mainline Firefox soon).

I think that making this available on the existing events is the right way to go, per Chrome’s rationale for not supporting Pointer events going forward. Namely, adding these properties to the corresponding mouse events would allow the correspoding Pointer events to be polyfilled more richly (which was the entire point of Chrome’s argument, that Pointer should be polyfilled).