Hi @leskos,
Yes, it would affect the gaze point given by the Unity SDK. EyeX would overwrite both the display area and the calibration (these two always do together), and you would end up with the eye tracker using a configuration for a different physical setup than the one you have. Since the eye tracker has to be calibrated for each specific screen setup, this also means that you have to do a custom calibration from the Tobii Gaze SDK (there are samples of that in the SDK).
The list of cases when the EyeX Engine would overwrite the display area (and calibration among other things) were just an example list. There is no fixed list of cases of when this happens and we cannot give such a list because it might change at any future release of the EyeX Engine. Internally we are using a call to Revalidate the eye tracking setup from different places in the code, it might be related to for example revalidating EyeX Settings or display settings because there might be a risk of inconsistency or because we know we need to update values due to system changes, or when the eye tracker is disconnected and reconnected, or when reloading the user profile. During revalidation all things are revalidated together to make sure the total configuration is consistent. This means that there are many different kinds of reasons for and chains of events resulting in revalidating the setup and there is no way of listing an exhaustive list including all corner cases of when this happens. It might be possible to work around if you have full control of the system – it might also not be possible to work around. I can’t say for sure. I would not know how to work around it myself, and I’m one of the developers who wrote the original revalidation routine in the EyeX Engine.