On Oct 1, 2012, at 8:20 PM, notig <[email protected]> wrote:
> basically when I use a desktop computer... I can send multiple types of input
> simultaneously (or what seems like simultaneously) . for instance I can
> scroll to the right and down at the same time by holding down my arrow keys
> left and right. Holding down the right arrow key doesn't suddenly "block"
> input from the other arrow keys.
In point of fact, it does: on Windows, every Window/control is associated with
an event loop, and events such as keypresses are sent to the event loop in FIFO
order. If the app never processes the left arrow key, then it won't see a
subsequent right arrow keypress:
http://en.wikipedia.org/wiki/Event_loop#Windows_applications
On "recent' versions of Windows (Win32 and later), each thread-with-UI-controls
gets its own event queue, which means that Process A's (lack of) input handling
won't impact Process B's, which is generally considered to be a good thing.
> In the unblock parked car game... you move a car by touching it and holding
> it down. But while you are touching the car you can't move another car (the
> input is blocked) . Of course there wouldn't be any point to moving more than
> one car at once... but what if you wanted to?
As you note, this does require hardware support, and not all Android hardware
supports multitouch, though Android 2.0 added support for multitouch events, so
it's probably fair to assume that most current hardware supports multitouch
events:
http://www.badlogicgames.com/wordpress/?p=1007
http://android-developers.blogspot.com/2010/06/making-sense-of-multitouch.html
However, this still requires that the application contain explicit multitouch
support:
> The code above has a bug on devices that support multiple pointers. While
> dragging the image around the screen, place a second finger on the
> touchscreen then lift the first finger. The image jumps!
Both hardware and application support is required. It is doable; the app just
needs to be coded to support it. See the above URL for example code.
> now you may be wondering why I'm asking bout multicore cpus... I was just
> curious.. would having the input on different threads somehow be beneficial
> ? So that as you are holding down the button the rest of the touch screen
> isn't locked? Or is that how input in general already works?
That is not how input in general works. In general, on most systems I'm aware
of, there is an "input queue" which contains various "messages" telling the
application what has happened, and it's up to the application to process these
messages however it deems fit. Moving some of the input queue handling to
another thread would complicate things, as UI-related code is "usually" (never
[0]) thread-safe; all event handling needs to be done on the UI thread just for
developer sanity.
- Jon
[0] OK, BeOS had a thread-safe UI, but it was also a PITA to write for.
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
