Re: contact geometry definition improvement suggestion

On 12/24/12 3:26 PM, ext Jacob Rossi wrote:
> *From:* Pierre Saslawsky
> *Sent:* ‎December‎ ‎22‎, ‎2012 ‎2‎:‎44‎ ‎PM
> *To:* public-pointer-events@w3.org
> *Subject:* RE: contact geometry definition improvement suggestion
> [..]
>
> > If "reasonable ubiquity" and "pervasive support" were requirements 
> in the development of specifications, we'd only write them in reaction 
> to what is experienced each time as a mess in the marketplace, instead 
> of acting as enablers of new applications and technologies.
> For a spec that deals with reporting of hardware events, it’s 
> important to demonstrate feasibility. Otherwise, you might end up with 
> APIs that can’t reliably be used (our principle goal for standards is 
> to promote interoperability). Worse yet, APIs designed in the absence 
> of well demonstrated implementability often result in flaws. For 
> example, an API might be inherently slow because it doesn’t have good 
> parity with the functionality hardware natively provides, thus 
> requiring a lot of software adjustment to fit what the hardware 
> provides to the API shape that the spec dictates.
>
> > Brush styluses are available; graphic artists and photographers are 
> using them on tablets in association to apps that did not exist a year 
> ago. A very distinctive feature of a brush is, of course, the shape. 
> It cannot be conveyed through the parameters we have now in the 
> PointerEvent and it would not take much effort at the spec level to 
> support these devices. All is needed is the addition of a 'mask-image' 
> (http://www.w3.org/TR/css-masking/#the-mask-image).
> This is a great example of my point above. What you’re proposing is 
> clearly a useful feature in the general sense. In fact, we 
> experimented with complex geometry support at one point. But what we 
> found was that:
> (a) almost no hardware was capable of actually reporting this data
> (b) on hardware that does support this, you generally have to do 
> software curve fitting to make the data useful, which is very slow 
> when you consider many touch devices provide input at 200Hz
> As hardware advances, implementing this attractive scenario might 
> become more realistic. When good hardware support exists, we can 
> ultimately design a better API that’s designed to leverage the 
> hardware more fully.
>
> > This change would not be a hinderance to the adoption of the spec 
> (if the mask is not available, UAs can omit it or leave it blank). So 
> could we include it now?
>
> Actually, it could be. For every feature, we need to demonstrate 2 
> interoperable implementations. Based on my reasons above, I do not 
> believe this could be achieved for your proposal (in the current 
> schedule chartered for this spec), which could block its progress.
> That said, I totally get your scenario and think it’s something worth 
> considering. We’re starting a list of possible “Version 2” features 
> and this is probably a great one to add

FYI, I added "support brush-type styluses" to the Pointer Events v2 
feature list:

<http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements#Requirements:_Pointer_Events_v.Next_Specification>

-AB

Received on Wednesday, 2 January 2013 13:40:40 UTC