input proposal talk
since github comment threads are clearly untrackable, i'll add some thoughts here:
11 Replies
do we need to establish the Deadzone concept here?
^ that can be a part of the Axis proposal
ifprobably out of scope, but this seems like a prime case for DPI awareness in response to our github discussion:Pointers.ButtonChangedis raised two consecutive times withIsDownset to true withinMouseClickConfiguration.DoubleClickTimemilliseconds, and theMouseState.Position'sXorYdid not change more thanMouseClickConfiguration.DoubleClickRange
...Ultimately a logical device (which I guess we should define as a single physical pointer input mode with which a single user can input one or more points), regardless of the number of points that device is reporting to the software, will always have one button state per capture...it seems to me like defining a logical device in terms of physical is an unnecessary limitation - one that is common for good reason, but i think it could be stretched further. the current abstraction is pretty damn good already, but maybe an
IPointer isn't a device, but rather the output of an IPointerDevice (a mouse, touch screen, tablet pen), which could provide any number of points at any time as an expectation, which can live and die at will, have unique runtime IDs, etc, and can have button state themselves (e.g. their click pressure, "grip", or sub-points in the case of gestures or point-cluster-based input systems). This could remove the need for intermediary data structures like PointerStatePoint
that being said, im ok with leaving it as is - I'd say we've already done more than the vast majority of pointer implementations and should feel happy with it.
but there is room for improvement / greater composability. since i dont have any terribly concrete recommendations for that (given that im still working on the axis proposal), perhaps it's best to shelve the conversation for silk 4. and maybe I rename the axis proposal to the Input Composability Proposal or whatevr
some of my concerns about pointers may not have anything to do with pointers at all - i think it's more to do with the Device layer, which is also quite thoroughly thought out already and doesn't need any revisions at this point
i think i will take my ill-defined concerns into my own proposal and see what i can do with them
speaking of runtime ids, I do think that individual PointerStatePoints should contain a unique ID and individual pressure valuesthey already contain pressure values in TargetPoint
as for unique IDs, I’m not sure this is something we can guarantee to get from all backends
we just have to trust that the indices line up for the same touch
I don’t want to break the world twice without good reason, if there’s something we want to do now we should do it now. Can you whip up an API?
not yet, I did think about it. If anywhere we should do it at the InputContext level given that this is all silk logic, our backends don’t do deadzones for us. Not sure of an API for that though, the single float API was pretty limiting I felt.
ill do my darnedest - do you need it today or can i cook a bit?
thats cool with me, im happy to include it in the "high level" part of my Axis proposal - i was thinking of having a more detailed deadzone description anyway
probably don't need it today, no.
yeah i agree we can't guarantee to get it, but in the case that it's not natively supported we can provide a default "persistence" implementation i'd be happy to write
ok - ill try to wrap things up today bc this has been a bit of a Text Hell we've found ourselves in, but certainly no promises
yeah no worries. and for the axis stuff, while that's not a target for 3.0 initial release, it'll be good to propose it at the same meeting so we definitely know the base API is sufficiently extensible
yeah agreed. personally i want to do my best to do both in parallel insofar as there is time for the sake of extensibility and creating intuitive API patterns, etc
ah yeah absolutely
grinding on this today, i have some Big Ideas im trying to prove out that should hopefully simplify things on both ends of the developer experience
we'll see if that pans out or i strip it back
is it ok if the proposal comes with some form of implementation for certain things?
could just be an example that is instead replaced with a spec
Ideally the document doesn’t contain implementations as these make it harder to review. Usage examples are okay though.
ok!