diff options
author | Sven Gothel <[email protected]> | 2013-03-19 00:22:28 +0100 |
---|---|---|
committer | Sven Gothel <[email protected]> | 2013-03-19 00:22:28 +0100 |
commit | f354fb204d8973453c538dda78a2c82c87be61dc (patch) | |
tree | f70748d4aaaacd442f9baa146be554120d8f8080 /make/scripts/rsync2here.sh | |
parent | 12e868f79938f44eba6f50313f977be76d8ea2bb (diff) |
OSX/CALayer: OSX/CALayer Threading Part3 - Run CALayer ops in a streaming design on main-thread w/o [infinitive] blocking
History:
Part1 commit 896e8b021b39e9415040a57a1d540d7d24b02db1 (Run CALayer Ops on current thread to avoid blocking)
Part2 commit 28c6472335b924080d638b33a28f8f4eedb459b1 (Run CALayer Ops on main-thread w/o blocking)
Dependency:
GlueGen commit 4becdfa125b07ff969d6540e1112735b53cd15eb (Fix RecursiveLockImpl* Timeout corner case)
Part2 misses essential locking of the OpenGL context (and it's surface upfront) while creating the
NSOpenGLLayer instance. The latter instantiates a OpenGL context shared w/ JOGL's, hence it cannot be locked.
Encapsulating NSOpenGLLayer creation/attachment and it's detachment/release in sub-classes
AttachNSOpenGLLayer and DetachNSOpenGLLayer, where instances will be streamed on main-thread.
Both tasks are triggered at associateDrawable(boolean bound).
The mentioned GL context locking requires disturbs the 'streaming' design considerably in AttachNSOpenGLLayer.
It is solved by attempt to acquire the recursive lock of the surface and the context via 'tryLock(maxwait)'
w/ screen-vSync-period/2. If the locks could not be acquired completly, the AttachNSOpenGLLayer instance
will be re-queued to the main-thread for later execution.
Before DetachNSOpenGLLayer is being streamed, it is validated whether AttachNSOpenGLLayer did run.
A recursive situation does happen w/ resizing an offscreen pbuffer drawable! Hence extra care is being taken.
Diffstat (limited to 'make/scripts/rsync2here.sh')
0 files changed, 0 insertions, 0 deletions