Hi @zack,
I recognize this problem as caused by a Unity bug. In certain situations the Unity Editor intermittently reports an incorrect value for Screen.height (height of the ‘Game’ window) making the calculations of the GazePoint way off intermittently. When I saw it, it happened only when one of the Unity Editor sub-windows (like ‘Game’, ‘Scene’, ‘Console’, ‘Inspector’) were detached from the main editor window, and maybe moved to a second monitor. Have you detached any of the sub-windows from the Unity Editor?
Also, I think the problem should not persist in standalone builds, but is a specific problem when playing the game from within the Unity Editor. I haven’t tested with a standalone game that creates two separate Unity windows though.
On a side note: the Gaze Trace feature is quite heavily filtered and is not really comparable to the behavior of the basic lightly filtered data you get from EyeTracking.GetGazePoint(). On the other hand, in scene 01 there is an option to use a filter which is very similar to the filter used by Gaze Trace. The movement of the filtered gaze visualization in scene 01 should be comparable to Gaze Trace to be able to conclude that the mysterious jumps are related to the Unity Editor and not the eye tracker data itself.