EVALUATION
If the timing is just right such that the following sequence
of events happens:
- there's a single onscreen surface created at some point, then disposed of
(invalidated) at the same time as..
- .. another thread calls Toolkit.sync() which ends up calling
D3DScreenUpdateManager.runUpdateNow()
We could end up with the updater thread missing the notify() from
runUpdateNow() and sleeping forever in runLock.wait().
There's a related problem in using runLock.notify() - we should be using
notifyAll() since there may be multiple threads calling
sync() and waiting for update to finish. Just using notify() will wake
up one of those threads, not necessarily the screen updater thread.
And there was an issue with the ordering of invalidating/replacing
onscreen surfaces in WComponentPeer.replaceSurfaceData() pointer by
one of the reviewers - we typically first replace teh surface, then
invalidate the old one. In WComponentPeer the order was reversed because
we needed to remove the d3d onscreen surface from the list of managed
surfaces. This could be done by other means, avoiding issues with creating
a graphics with already invalidated surface.
|
Java