- moving filter-related code out of the layercontroller
by creating a Filter subclass : CVFilter
- making coreimage filters available to javascript when running on osx
Note : this is a work in progress and implementation is still unfinished
(coreimage filters won't work in this revision)
refactoring the feedFrame/renderFrame/getTexture flow to make a more
clever use of memory and autorelease pools
started implementing CVFilter
(on the way of having CoreImage filters usable from javascript)
obsoleted since long, it cleans up the Screen api
eventually we might want to have more screens
with magnification in future, algos like those
found in Mame, h2x and such
any subclass of CVCocoaLayer with a controller associated to it can now
be controlled through the filterpanel.
The filter panel for a specific layer can now be opened by
double-clicking on the layer name in the listview.
a bit of refactoring in CVFilterPanel/CVLayerView/CVLayerController
has been done to allow viewless layers to be created and eventually
controlled through a filterpanel
I'm leaving calls to JS_SetContextThread() and JS_ClearContextThread
commented-out because we still need to carefully check what's going to
be called asynchrounosly from different threads
(I'll remove superfluous onse later on)
the most serious fix here was to flag the cocoa keyboardcontroller as
indestructible, to avoid crashes when loading a new script after a reset()
(the keyboardcontroller was destroyed while still used as a singleton,
so the new script was referencing a dead instance)
various cleanings and fixes while introducing the new
JSExecutionContext internal class (used by the JsParser to
rapresent the execution context of a script).
various fixes and cleanings here and there but more are still needed ...
and at some stage I'd like
to get rid of most of the macros in our internal javascript
abstraction in favour of a more solid api... but first we needed
the internal javascript engine to work properly and allow loading
multiple scripts without having their global context to collide.
We are there now ... but most of the old code needs to be refactored
to take advantage of the new approach ( many js objects still make use
of the global_context/global_object hold by the JsParser)
KbdController is now a singleton as well and is able to propagate
keystrokes to multiple listeners
generalizing the ControllerListener API
(must still get rid of the 'frame()' method in favour of the more
generic 'call()' one)
TriggerController is now a singleton (KbdController is going to become a
singleton as well)
the same script can now be loaded multiple times , globals won't collide
anymore since each script will have its own context
(but still running in the same jsruntime)
using JS_MaybeGC() to try garbage-collecting as soon as necessary
If something has been alloc'd through the 'alloc' message, it must be also
released esplicitly. Moreover , if it has been alloc'd there is no need to retain it ...
since no-one called autorelease on that instance yet.
