Long story short, you have to create a shared library which will be added to the list of preloaded libraries before the application itself loads. The shared library loader will load your library and any other libraries your application depends on and your application. When symbols are resolved, any symbols will get first resolved from your shared library (if defined there) then from standard library or other shared libraries your application uses. What this means?
Well, if we have a function named malloc in our preloaded shared library, when the application gets loaded by the system, all references to malloc will be resolved to one in the preloaded shared library, instead of one from standard library, so basically, the application will use our version of malloc.
Of course, having it replaced would not help too much if we don’t have a way to call the old (standard library provided) version of malloc when memory needs to be allocated. Fortunatelly, libdl offers a way to do this, in the form of RTLD_NEXT parameter. If you pass this parameter to the function when looking for the address of a symbol (function), it will return (as it says) the next symbol matching the name. In our case the one provided in the standard library.

For example if you create a shared library with the following two functions:

void *malloc( size_t size )
{
	static void * (*func)(size_t);

	printf("Entering %s\n", __FUNCTION__);

	if (!func)
	{
		// get reference to old (libc provided) malloc
		func = (void *(*)(size_t)) dlsym(RTLD_NEXT, "malloc");
	}

	printf("malloc(%d) is called\n", (int)size);

	// call old (libc provided) malloc
	void* ret = func(size);

	return ret;
}

void free( void* pointer )
{
	static void (*func)(void *);

	printf("Entering %s\n", __FUNCTION__);

	if (!func)
	{
		// get reference of old (libc provided) free
		func = (void (*)(void *)) dlsym(RTLD_NEXT, "free");
	}

	printf("free is called\n");

	// call old (libc provided) free
	func(pointer);
}

and add the library to list of preloaded libraries, it will display a list of calls to the malloc and free functions:

$ export LD_LIBRARY_PATH=yourinterposedlibrary.so
$ ls

Entering free
free is called
Entering malloc
malloc(41) is called
Entering free
free is called
....

Using this method, most of the functions from the standard library can be replaced with our own function. However one of them seems to be particulary difficult: calloc.
Why this is more difficult than the other functions? Because turns out that on Linux the dlsym function which has to be used to retrieve the libc version of calloc uses itself this function, which ends up in infinite recursion (since it gets replaced by our own version wich gets called by dlsym which in turn calls calloc which is the interposed version which in turn calls dlsym which in turn … you get the ideea.

In order to fix this issue, seems like we need somehow not to call libc provided calloc until we get reference to libc provided calloc. Easier to say than do .. turns out we need to preallocate some memory wich gets returned when the dlsym function is called to retrieve the address of libc provided calloc. Once that is completed, we can get rid of the hack and use directly the libc provided calloc in order to perform calloc when required, from our interposed calloc function.

Seems complicated or at least not so attractive path to follow. I was wondering what happens if calloc returns NULL until we actually get the libc provided one? It is anyway used in ld.so, the ones who wrote it should take care of handling this situation (maybe failling to load the application itself?). Turns out, if we return NULL for the memory which needs to be allocated by dlsym function while we are trying to get the address of libc provided calloc works just fine (at least on my computer, with my version of Linux). Now things get a lot simpler for interposing calloc:

// our temporary calloc used until we get the address of libc provided
// one in our interposed calloc
static void* temporary_calloc(size_t x, size_t y)
{
	printf("empty calloc called\n");
	return NULL;
}

extern "C" void *calloc( size_t nelements, size_t elemetnSize)
{
	static void * (*calloc_func)(size_t, size_t) = 0;

	printf("Entering %s\n", __FUNCTION__);

	if (!calloc_func)
	{
		// before trying to get the libc provided
		// calloc, set the calloc function to the temporary
		// one returning NULL.
		calloc_func = temporary_calloc;

		// dlsym will call again this calloc in which we are,
		// but seems like it handles just fine if we are
		// returning NULL
		calloc_func = (void *(*)(size_t, size_t)) dlsym(RTLD_NEXT, "calloc");
	}

	void* ret = calloc_func(nelements, elemetnSize);

	return ret;
}

Adding this to the previous shared library and interposing it, will also display when the application calls calloc proving that interpose was successfull.

http://www.anddev.org/viewtopic.php?p=29939

If you are looking only for using the containers and so from STL, not using iostream & company (which requires building the library itself), using this should be as easy as copying the header files in your project and start using it  as most of the functionalites come from template code which is contained in the header files.  So I have added the stlport folder with the header files to my project and tried to build the project with some STL testing code. However as soon as I start building it, I get this error:

obj/xxxx.o: In function `~vector':
[...]/native/stlport/stl/_alloc.h:213: undefined reference to `std::__node_alloc::_M_deallocate(void*, unsigned int)'

Checking the _alloc.h file we see there isthis comment:

// Default node allocator.
// With a reasonable compiler, this should be roughly as fast as the
// original STL class-specific allocators, but with less fragmentation.
// Define _STLP_USE_SIMPLE_NODE_ALLOC to use __new_alloc instead, which
// can be implemented without out-of-line functions.

Which probably means that by defining _STLP_USE_SIMPLE_NODE_ALLOC during the build probably will fix this issue. So I have added it to CFALGS, and seems like build is just fine, no more errors thrown.

More test need to be performed to see if everything is ok.

Instead, a much better approach would be to change the build process to make this happen automatically. For this there are couple of approaches, from which I find as easiest to put in practice to use the container’s auto-deploy feature. Both Felix and GlassFish (these I’ve played with), but probably the others have this feature to monitor a folder for new jar files, and when they appear in the folder, they automatically deploy them. When bundles are removed from the folder, they are un-deployed from the container. If the jar file changes, it is either updated or redeployed.

GlassFish already supports this deployment process. The folder where is watching for new bundles is located at:

    glassfishv3/glassfish/domains/domain1/autodeploy/

for .war applications and

    glassfishv3/glassfish/domains/domain1/autodeploy/bundles

for OSGI bundles.

In order to have this deployment active in Felix, you will need to install an additional OSGI module, called File Install. Can be downloaded from Felix’s web page. You just have to put it in

<felix install>/bundles/

folder and will be deployed next time container starts.
The folder where Felix will watch for bundles can be configured using the  felix.fileinstall.dir property from the file located at:

<felix install>/conf/config.properties

Having these said, all what remains to be done is to configure the latest step of build to copy all the bundles which need to be deployed in the target folder where it will be deployed by the OSGI container. This step depends on what IDE, build system,etc are you using.

For users with Maven, you can add for example an additional module called let’s say deploy, who’s job would be to deploy the application. You will have to add all artifacts and dependencies which need to be installed in this module’s POM file, then you can add a build step like in the file bellow in order to have these artifacts copied in the target folder:

<!-- usual POM stuff -->
...
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-dependency-plugin</artifactId>
      <executions>
        <execution>
          <id>copy-bundles</id>
          <phase>validate</phase>
          <goals>
            <goal>copy</goal>
          </goals>
          <configuration>
            <artifactItems>
              <!--  Our bundles which need to be deployed -->
              <artifactItem>
                <groupId>group id of your artifact</groupId>
                <artifactId>id of your artifact</artifactId>
                <version>version of your artifact</version>
              </artifactItem>
              <artifactItem>
                <groupId>group of your artifact</groupId>
                <artifactId>id of your artifact</artifactId>
                <version>version of your artifact</version>
              </artifactItem>
                 ...
            </artifactItems>
            <outputDirectory>target folder where container looks for OSGI bundles</outputDirectory>
            <overWriteSnapshots>true</overWriteSnapshots>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Of course this can be made in many ways, this is one which worked for me. Feel free to add comments and suggestions over the process

A crude approach would be to use threads. For each object we are waiting on, we start a thread to wait for an event or timeout, and in the function itself, after threads are spawned, we simply wait to see if either one of threads notify us about it’s object being signaled, or we timeout. One of this approaches’s flaw is that for each object we are trying to wait on, uses a thread. But if we look carefully, we notice, this entire spawning threads,listening for getting notified fits perfectly into observer pattern. The caller needs to observe if something happens with the objects we are waiting on (they got signaled or not), in a given time interval, or if not, timeouts. The objects we are waiting on should also let known their observers if something happent to them (they got signaled)

So, considering wxWidgets, we could use it’s wxCondition class, which gives us a platform-independent condition variable. We need to have a object on which we could wait, which can be signaled,and which can be observed. wxCondition fits the bill,except .. noobservers. So let’s extend it, to allow objserver management:

class Event: public wxCondition
{
	protected:
		std::list< Event* > mObservers;
		wxMutex mObserverMutex;

	public:
		void addObserver(Event* e)
		{
		        wxMutexLocker observerLock(mObserverMutex);
		        mObservers.push_back(e);
		}

		void removeObserver(Event* e)
		{
		        wxMutexLocker observerLock(mObserverMutex);
		        mObservers.remove(e);
		}
}

We also need to keep track if event is signaled or not. wxCondition does not give us this ability. Also, by reading wxCondition documentation, we see wxCondition will need a wxMutex to work, so let add these:

class Event: public wxCondition
{
	protected:
		...
		bool mSignaled;
		wxMutex mMutex;

	public:
		Event()
		:wxCondition(mMutex),
		mSignaled(false)
		{
		}

		bool Signaled()
		{
			return mSignaled;
		}
}

For things to work as they should work, we need to rewrite Signal() to notify it’s observers and set mSignaled member variable, and also we should rewrite Wait() and WaitTimeout() to clear it, and of course these should work with the own mMutex mutex:

class Event: public wxCondition
{
	public:
		...
		void Signal()
		{
		    wxMutexLocker lock(mMutex);
		    wxMutexLocker observerLock(mObserverMutex);

		    std::list< Event* >::iterator it = mObservers.begin();
		    while(it != mObservers.end())
		    {
		            (*it)->Signal();
		            it++;
		    }

		    wxCondition::Signal();
		    mSignaled = true;
		}

		wxCondError Wait()
		{
		    mMutex.Lock();
		    mSignaled = false;
		    return wxCondition::Wait();
		    mMutex.Unlock();
		}

		wxCondError WaitTimeout(unsigned long timeout)
		{
		    mMutex.Lock();
		    mSignaled = false;
		    return wxCondition::WaitTimeout(timeout);
		    mMutex.Unlock();
		}
}

At this moment we have a Event class which can be observed, and while observed, if it is signaled, will also signal it’s observer. So, how can we use this to implement WaitForMultipleObjects() function?
First, let’s define some constants, to be in concordance with Windows code:

#define WAIT_OBJECT_0 0
#define WAIT_TIMEOUT 0x00000102L
#define WAIT_ABANDONED 0x00000080L
#define WAIT_FAILED 0xFFFFFFFF

WAIT_OBJECT_0+number of signaled object is returned when one of the objects we are waiting on gets signaled.
WAIT_OBJECT_TIMEOUT is returned if none of the objects we are waiting on are signaled.

WaitForMultipeObject() gets as parameter number of objects it should wait on, an array with the objects, a boolean stating if it should wait on all objects or not, after how many milliseconds it should timeout, and if it is aleratable or not.
Since waiting on all objects to get signaled is trivial to implement (we wait on all objects one after another until either all objects get signaled or we timeout), we will skip this part of implementation.
The alertable flag we are not interested in, it is used only to specify if APC-s can be run or not while we are waiting on objects. Since we are not implementing APCs, we can simply ignore this flag.

int WaitForMultipleObjectsEx(unsigned long numObjs, Event** objs,
                             bool waitAll, unsigned long timeoutMillis, bool alertable)
{

Note that we are passing an array of our Event class,not wxCondition!

Specification also states that if timeout period is 0, we should not wait on objects get signaled, but just check if they are signaled or not, and return. So let’s check that first inside the function:

	if(timeoutMillis == 0)
	{
		for(int i(0);i < numObjs;i++)
			{
				return WAIT_OBJECT_0+i;
			}
		}

		return WAIT_TIMEOUT;
	}

If we have timeout specified and different than 0, we should start waiting until either one of objects get signaled, or we spend more than specified time in function (and then we return with timeout). So, we mark when we started to wait, create a observer event, and add it as observer to all events we are waiting on:

	wxLongLong startmsec(wxGetLocalTimeMillis());

	// create a observer event and subscribe it as observer to all events we are waiting on
	Event observerEvent;

	for(int i(0);i < numObjs;i++)
	{
		objs[i] -> addObserver(&observerEvent);
	}

Now, if one of our observed events get signaled, the observer event also gets signaled. Now let's use the remaining time from timeout to wait until observer gets notified or timeouts on wait:

	wxLongLong usedmsec = wxGetLocalTimeMillis()-startmsec;

	// how much we should sleep?
	usedmsec = timeoutMillis-usedmsec;

	wxCondError r = observerEvent.WaitTimeout(usedmsec.ToLong());

After either one of observed events get signaled, or the required timeout milliseconds pass, WaitTimeout() function returns. We now have to check the return code. If returns timeout, we also return timeout. If returns no error, it means one of objects we were waiting on got signaled, so we have to find it's index in object array and return WAIT_OBEJCT_0+<index of object signaled>. In both cases, before returning, we should to deregister the observer event from the list of observed objects:

	if(wxCOND_TIMEOUT == r)
	{
		// if wait returned timeout, we also return timeout
		return WAIT_TIMEOUT;
	}
	else if(wxCOND_NO_ERROR == r)
	{
		// if wait succeeded, we unregister the observer event from observed events
		// meanwhile we check to see if object got signaled or not, to find out the
		// index of the signaled object.

		bool gotSignaledObject = false;

		// we should return WAIT_OBJECT_0 + index of signaled object, so let's start
		// at WAIT_OBJECT_0
		int res = WAIT_OBJECT_0;

		for (int i(0);i < numObjs;i++)
		{
			if (!gotSignaledObject && objs[i] -> Signaled())
			{
				// got the index of signaled object.
				gotSignaledObject = true;
				res += i;
			}

			objs[i] -> removeObserver(&observerEvent);
		}

		return res;
	}

	return WAIT_FAILED;
}

This is all. So, let's see a simple application which test the functionality:

class MyApp: public wxApp
{
	public:
		bool OnInit();
} myApp;

// the events we will wait on
Event e1, e2;

class T : public wxThread
{
	public:
		void* Entry()
		{
			printf("Thread started\n");
			usleep(10000);
			printf("Event 1 signaled\n");
			e1.Signal();
			return 0;
		}
};

bool MyApp::OnInit()
{
	Event e;
	T* t = new T();
	t->Create();
	t->Run();

	Event* evs[]={&e1,&e2};
	printf("Waiting \n");
	int res = WaitForMultipleObjectsEx(2, evs,false, 2000,false);
	printf("Completed %d\n", res);

	return true;
}

IMPLEMENT_APP(MyApp)

Note: Code provided here is for educational purposes. It cannot be used in any projects, specially commercial, without my consent.

I have run couple of tests about what happens in various situations when client connects,disconnects,etc and found out the following:

• when a new connection is made to server, QTcpServer will emit a newConnection() signal, and then, for the connected client we can get back a QTcpSocket instance, using nextPendingConnection().
• the QTcpSocket contains the socket descriptor used for communication.
• hen there is data to be read or data was written to socket, QTcpServer emits signals related to this, and the sender of the signal is a QTcpSocket instance. One could get it by converting the sender() to QTcpSocket*. For a given client, the instance of QTcpSocket will be every time the same.
• if previous client disconnected and a new client connects, although it is possible to have the same socket descriptor used for communication, the instance of QTcpSocket returned by nextPendingConnection(), and subsequently used in signalling events, will be different one.

Because for each client gets a different and very own QTcpSocket instance, and has this instance while disconnects, one simple approach would be to use this QTcpSocket instance to identiy for what client the event is happening.

But how can we do this?

First, let’s assume we have a Server class, which has a QTcpServer member variable with it’s signals (newConnection()) connected to a slot in Server.
Also, let’s assume our client-related information is stored in a class Client.
For identifying on which Client we get data/data was sent/ error occurred, we simply use a simple QMap stored as a member variable, which maps QTcpSocket* to our Client instance.

QMap<QTcpSocket*, Client*> mClients;

When a new connection arrives on our QTcpServer, the Server slot we set up gets called. Here we retrieve the QTcpSocket, create our Client instance, connect some signals, and store it in our map for later identification:

// connected to mTcpServer::onNewConnection()
// gets called each time a new connection arrives on server
void Server::NewConnection()
{
   QTcpSocket* connection = mServerNextPendingConnection();

   if(connection)
   {
       Client* client = new Client();

       // connect signals to handler slots

       // we assume Server has a slot Error(QAbstractSocket::SocketError))
       connect(connection, SIGNAL(error(QAbstractSocket::SocketError)),
          this, SLOT(error(QAbstractSocket::SocketError));

       // we assume Server has a slot readyRead()
       connect(connection, SIGNAL(readyRead()), this, SLOT(readyRead()));

       //we assume Server has a slot disconnected()
       connect(connection, SIGNAL(disconnected()), this, SLOT(disconnected()));

       //store the TcpSocket,client pair in map
       mClients[connection] = client;
   }
}

When data arrives on socket, the TcpSocket for the given connection will notify server by calling the slot we set up in the incoming connection. Bellow is how you can retrieve on which client this happened:

// gets called when data is available on one of our client QTcpSockets
void Server::readyRead()
{
    // retrieve our sender QTcpSocket
    QTcpSocket* connection = qobject_cast(sender());

    // get our Client
    Client* c = mClients[connection];

    // ...
    // do the processing you have to do with the data comming for this
    // client
    // ...
}

We can retrieve the Client on same way for errors, or when gets disconnected, as these also get their own signal, and the sender for the signal will be the associated QTcpSocket.

As a side note, when disconnected() slot is called, the returned QTcpSocket instance, although it is the same one for a given client as the one used in read and write, will have the underlying socket descriptor set to -1. This means that although we could use socket descriptor as a key in our client map when event such as there is data to be read or data was written to identify the client, on disconnect we cannot figure out for what client we need to free it’s data and resources.

Sometimes you are bound to use a unified signal-slot for passing various informations between couple of objects interacting with each other. While the information needs to be of different type, sometimes you are bound to same unified mechanism for a variety of objects, because having one signal-slot for each object type being passed around is simply not viable.

Example:
    In a hierarchical model-view-controller architecture, controllers on diverse layers can communicate with eachother by events. One controller can handle a event, bubble it up to it’s parent controller, or send it down to it’s child controllers. Implementing one handling method for each possible event passed around is not viable, since this means all controllers need to implement that method. Also, adding new events to the system is hard, because you have to rewrite all controllers to handle that new event type, or to pass it around.
Since one event handler per event type is not viable, another approach would be to have a generic event handler mechanism, which handles all the event types, and have different event types subclass a parent Event, and in the event handler, according to event sent as parameter, to respond to given events, if their type is appropiate.

With Qt this could be implemented by adding to each object a event(Event*) signal and fireEvent(Event*) slot, and all interested parties register to event(Event*) signal, and get notified when fireEvent() is called. One downside of this approach is that all registered slots get called, even if they are not interested in the given event. Even worse,the slots who are not interested in event still have to check if the event is an event they are interested in, just to realize the event is not of their interest.

So, we need to somehow fire events, but to notify only those events who are interested in a given event type. And of course, to rely on Qt’s cool signal-slot mechanism.

First, we declare a base Event class, instance of which gets passed around. Later, for new events, we just extend this base class, and pass instance of the new class to signal-slot mechanism.

Then, we need to decide how we gonna select what event we want to react on. For example, we can filter events by class name. So, we need a mechanism which will allow us to return a type of event either from an instance of object, or statically from class. I have created a template to help with this (and also allow easy change later if I want to replace it with something else):

template <class T>
        class EventHelper
        {
           public:
              static QString type()
              {
                return T::staticMetaObject.className();
              }

              static QString type(QObject *e)
              { 
                return e->metaObject()->className();
              }
        };

We can use this either by calling it with a class parameter like:

QString type = EventHelper<AppEvent>::type()

or with an instance of Event or another class extending Event, like:

QString type = EventHelper<Event>::type(instance of event here)

In order to route events, we create a EventRouter object. We will use this object to register various objects interested in handling events, and we will fire events using this EventRouter class. When firing events, EventRouter will take care of signaling only slots who are interested in the given event type.

For registering objects interested in given event type:

eventRouter.registerTarget(QString& type, Target* t)

where Target is a class which has slot for handling event, like

void handleEvent(Event* e)

When signaling event, EventRouter should take care of signaling only the interested parties. But how can this be accomplished, while still using the Qt’s event / slot mechanism?
One approach would be to use an intermediate object, as a relay object. For each event type we register Targets for, EventRouter holds a helper object, to which actually connects the signal and slot of the EventRouter and Target. So, the sole purpose of helper object is to relay the event to it’s Target’s:

class EventRouterHelper : public QObject
{
    Q_OBJECT

    public:
        EventRouterHelper(QObject* parent = NULL);

    signals:
        void event(Event* e);

    public slots:
        void fireEvent(Event* e) { emit event(e);}
};

All Target’s handleEvent slots get registered to EventRouteHelper’s event() signal. This allows using Qt’s mechanism to signal event to all Targets.

So EventRouter’s remaining job is to wire up everything and according to the type of signaled event, to retrieve the correct EventRouterHelper object and use it to fire the event to intersted Targets:

class EventRouter : public QObject
{
    Q_OBJECT

    public:
        EventRouter();
        ~EventRouter();

        void registerTarget(const QString& clazz, Target *target );
        void unregisterTarget(Target *p);

    public slots:
        void fireEvent(Event* e);

    protected:
        QMap<QString, EventRouterHelper*> mRoutes;
        QMap<Target*, EventRouterHelper*> mRouteObjects;
};

When registering Target, we check if we have a helper object for this event type. If we don’t have yet, then create one, otherwise hook up the signal/slots as required:

void EventRouter::registerTarget(const QString &clazz, Target *target)
{
    EventRouterHelper *o = mRoutes[clazz];

    // if we don't have helper object, create one
    if (o == NULL)
    {
        // create an EventRouterHelper which we use to hook onto
        // the signals and events
        o = new EventRouterHelper();
        mRoutes[clazz] = o;
    }

    // now connect up all signals and slots between target and event helper
    connect(o, SIGNAL(event(Event*)),
            target, SLOT(handleEvent(Event*)));
    mRouteObjects[target] = o;
}

Firing event is easy, just get the helper object for the given class, then fire the event. Because all Target slots are registerted on helper object’s signal, all Targets get notified automatically:

void EventRouter::fireEvent(Event *e)
{
    // get class of event
    QString clazz = EventHelper<Event>::type(e);

    // get helper object
    EventRouterHelper *r = mRoutes[clazz];

    if(r)
    {
        r->fireEvent(e);
    }
}

Source of sample application can be downloaded from here ]]> http://blog.bigpixel.ro/2010/04/29/selective-slot-activation-in-qt-using-signal-slot-mechanism-3/feed/ 0 http://blog.bigpixel.ro/2010/04/23/storing-pointer-in-qvariant/ http://blog.bigpixel.ro/2010/04/23/storing-pointer-in-qvariant/#comments Fri, 23 Apr 2010 08:39:45 +0000 admin http://blog.bigpixel.ro/?p=180 You can store many types of data into QVariant, like int, string, etc. Also you can store pointers, but only pointers to void (void*).
But what happens when you want to set a property of a object to a instance of class, with setProperty, and after that, you want to retrieve that property? QVariant accepts void*, so you can do something like the following, to store it into QVariant:

QVariant v = qVariantFromValue((void *) yourPointerHere);

and then something like this, in order to retrieve it back from QVariant:

yourPointer = (YourClass *) v.value<void *>();

Having this done each time you have to get the property or set the property is a bit tendentious. We can make this more friendly, using templates:

template <class T> class VPtr
{
public:
    static T* asPtr(QVariant v)
    {
	return  (T *) v.value<void *>();
    }

    static QVariant asQVariant(T* ptr)
    {
	return qVariantFromValue((void *) ptr);
    }
};

So how do you use this? Assuming you have a class MyClass, and you want to store a pointer to this class as a property of a QWidget, or any QObject, or you want to convert it to QVariant, you can do the following:

MyClass *p;
QVariant v = VPtr<MyClass>::asQVariant(p);

MyClass *p1 = VPtr<MyClass>::asPtr(v);

I think this is more developer friendly than having to write each time those conversion code sequences.

• flam3 cannot render only one part of the image, although large images can be rendered in stripes to overcome out of memory error. Still, as it is originally, either with stripes or not, flam3-render can render one image only, not part of the image.
• somehow the file location need to be resolved. the render slaves need the information describing what to render (the .flame3 file), and they need to store somewhere the result of their rendering. This means between the server and render slaves we need a shared file system,where/from where both can read/write, or the server need to act also as a file server, allowing slaves to upload render results and download render informations.

For now, I have changed flam3 package to allow partial rendering only.
In order to ease the parameter passing, I have modified the code that now settings can be passed either through environment variables, or through command line arguments. All environment variables can be set from command line using [name]=value format, where [name] is the name of the environment variable. Please note, command line settings have higher priority over their environment counterparts.

Also, couple of new options were added, for rendering only part of the flame:

• –help – display the help
• minstrip=[number] – the minumum strip number to be rendered.
• maxstrip=[number] – the maximum strip to be rendered.
• strip=[number] - the strip to be rendered.

Please note:

• for all this parameters, you will have to set nstrips value. Also, the value of these parameters should between 0 and nstrips.
• Also, if minstrip and maxstrip is provided, then render is between minstrip inclusive and maxstrip-1 inclusive. (minstrip=0 and maxstrip=1 will render strip 0, minstrip=1 maxstrip=1 will render no strips)
• providing strip=[number] will render only the given strip.

Sources can be downloaded from here: flam3.tar.gz

Next step would be the server and render slaves.

 

protected void onCreate(Bundle savedInstanceState)
{

    	super.onCreate(savedInstanceState);

    	// make window full screen
    	requestWindowFeature(Window.FEATURE_NO_TITLE);
    	getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
    			WindowManager.LayoutParams.FLAG_FULLSCREEN);

 .. do your usual initialization stuff
 }

Version: OpenGL ES-CM 1.1
Vendor: Qualcomm
Renderer: Adreno
Opengl extensions:

• GL_AMD_compressed_3DC_texture
• GL_AMD_compressed_ATC_texture
• GL_ARB_texture_env_combine
• GL_ARB_texture_env_dot3
• GL_ARB_texture_mirrored_repeat
• GL_ARB_vertex_buffer_object
• GL_ATI_compressed_texture_atitc
• GL_ATI_texture_compression_atitc
• GL_EXT_blend_equation_separate
• GL_EXT_blend_func_separate
• GL_EXT_blend_minmax
• GL_EXT_blend_subtract
• GL_EXT_stencil_wrap
• GL_OES_EGL_image
• GL_OES_blend_equation_separate
• GL_OES_blend_func_separate
• GL_OES_blend_subtract
• GL_OES_compressed_ETC1_RGB8_texture
• GL_OES_compressed_paletted_texture
• GL_OES_draw_texture
• GL_OES_extended_matrix_palette
• GL_OES_framebuffer_object
• GL_OES_matrix_palette
• GL_OES_point_size_array
• GL_OES_point_sprite
• GL_OES_read_format
• GL_OES_stencil_wrap
• GL_OES_texture_cube_map
• GL_OES_texture_env_crossbar
• GL_OES_texture_mirrored_repeat

Unfortunately resource loading as shared library seems to not work, it requires some more investigations why this happens (Theoretically it should work, maybe there are some differences related to shared library path..)