Hi Russell,
Explicit and implicit casting is actually what I would suggest to use and what we are using in the EyeX SDK samples that have a GUI. Any roundoff errors should be insignificant compared to the overall precision possible with eye tracking. I can’t remember now why the coordinates ended up being real values in the API – we are after all talking about physical pixels which only makes sense as integer values. Anyhow and anyway, there is code in the ActivatableButtons sample that uses the ClientToScreen function.
Furthermore, since what you want to have is buttons that detect gaze, I would like to point out that we have this feature in the EyeX Engine API. If you define a region on the screen to have the Gaze Aware behavior, and inform the EyeX Engine of this region when the engine asks for information about that particular part of your application window, the EyeX Engine will raise events when the HasGaze status of that region changes – true if it is being looked at, and false otherwise. The Gaze Aware behavior feature also takes into consideration other EyeX region around the current region, the empty space with no regions and regions in other application windows next to yours, when deciding if the user is looking at this particular region or not. The filtering and heuristics are quite extensive to create a consistent user experience – and you can tap into this not having do implement your own filtering and heuristics.
The ActivatableButtons sample shows how to define a region with the Activatable behavior. The GazeAware behavior is similar but does not require the user to press a button, and you can define a delay in ms how long the user has to look at a region before the EyeX Engine raises a ‘HasGaze = true’ event.