Run attache test. Move mouse pointer close to the right border of the green rectangle, click it. See that when the rect. moves from under the pointer we don't receive a MouseExited event for the green rectangle (or mouse entered for the blue one in the background).
The problem is that in prism we respond to events in one pulse:
on each pulse:
- system events are put into the fx queue by the rendering thread
- events are processed (objects are moved around etc)
- animation is ran (world updated)
- scene is rendered
- we're done, unless there are more events or animation, we'll be waiting for the next pulse
In this case we move the rectangle, but mouse handling code is supposed to be executed on the next pulse , but it may happen seconds later (or never) - in response to user events ,for example.
We perhaps need to trigger another pulse if the scenegraph had changed during current pulse, to make sure the events are delivered.
The problem is that in prism we respond to events in one pulse:
on each pulse:
- system events are put into the fx queue by the rendering thread
- events are processed (objects are moved around etc)
- animation is ran (world updated)
- scene is rendered
- we're done, unless there are more events or animation, we'll be waiting for the next pulse
In this case we move the rectangle, but mouse handling code is supposed to be executed on the next pulse , but it may happen seconds later (or never) - in response to user events ,for example.
We perhaps need to trigger another pulse if the scenegraph had changed during current pulse, to make sure the events are delivered.