[logicalshift]

I’ve been keeping an eye on the various UI libraries when they come up: right now it seems to take me around a month to add a new one so I’m waiting for one to get traction.

Something else that’s a problem is that as a drawing app, FlowBetween wants to be able to get access to data from a digitizer: pen pressure and tilt in particular. A lot of UI libraries don’t think to pass that through from the operating system, or have an awkward API (browser support is also very spotty for this)

[chrismorgan]

Yeah, lack of support for different input media has been a real pain point for me—most of the developers of these things have mice only, and don’t stop to bother about touch or pen input. I use a Surface Book which has mouse, touch and pen, and I like to use all three forms at various times.

If you’re trying to do touch and pen on non-web platforms, things tend to be very messy if you want to handle all three types of pointers optimally.

But browser support spotty? I find the pointers events API a marvellous abstraction over platform differences, doing the right thing automatically for >99% of cases, and making the remaining cases possible. The only thing I feel it actually lacks is standardised gesture support for touch. I wrote a simple pressure-capable drawing app a couple of years back in the very early days of pressure-sensitivity (back when Edge was the only browser on Windows that supported it, so I targeted Edge only until other browsers got it), and I found it a refreshingly straightforward system to work with. And since then, everyone implements things like tilt and pressure.

So I’m curious to hear what you’re quibbling over, as someone that’s been using this stuff in anger more recently than I.

[logicalshift]

I suspect some of my experience is now out of date, as it's now spread out over quite some time. The most recent issue I had to deal with was Chrome: when drawing the canvas at high-res it was being a bit slow at blitting some bitmaps and so was running at 30fps. Something is tied to the framerate with the pointer events implementation and so the events also lagged behind, which made drawing on the canvas quite difficult as the display was 250-500ms behind the user. Eventually 'fixed' by turning the resolution down, but it was a real pain finding what part of the application had got behind (FlowBetween being designed not to lag but to catch up when the display can't keep up). That's quite a subtle one and the pointer events lagging is easily mistaken for the frame rate lagging.

Other browsers don't do this, but they've had a few other issues: what I remember in particular - some only support pressure information using the touch API, and some seemed to support pressure information on different APIs on different platforms, so both pointer events and touch events were needed.

All of these are maturity issues rather than real problems with the API, though and I haven't re-checked some of the older issues recently - that Chrome issue was still happening back in January so might still be around, but the others I last encountered over a year ago so may have been fixed by now.

[chrismorgan]

If you haven’t been using it, make sure to use PointerEvent.getCoalescedEvents where available, which unlinks the events from the display frame rate. Anything using pointer events for drawing should use it. (But remember that events can come in at any speed, e.g. a 240fps pen should coalesce four events per 60fps frame—so make sure you can cope with lots of events.)

I believe that the pointer events API is in current browsers now uniformly superior in functionality to the touch events API which it obsoletes.