- 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)
and everything seems now to build and work on linux as well
(but further tests on filters are necessary since some functionalities
could have been broken during the refactoring)
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
disabling explicit calls to JS_GC() for now, still those
seem to trigger the deadlock (garbage-collection happens anyway
since jsapi will still implicitly take care of it)
and deactivating some calls to JS_BeginRequest()/JS_EndRequest() ...
it seems that when code is called directly from the javascript
wrapping js-api calls in a request dead-locks.
It could also be that we leave an opened-request somewhere and so
deadlocks are only our fault, but I checked carefully and it seems
unlikely (but further checks will follow)
In the meanwhile , disabling request-wrapping in geo_layer_js seems
to make everything work properly (gc() garbage-collects smoothly and
everything runs with neither crashes nor deadlocks)
xant