Originally Posted by freemangordon (Post 1185667)

@DavyP - thanks for the last patches, now opera runs. In short - everything is fine :)

I've played a little bit with cvm code and the result so far:

JBenchmark2, no overclock, charger connected, using max score from several runs:

landscape:
DavyP cvm - 862
freemangordon cvm - 874

portrait:
DavyP cvm - 760
freemangordon cvm - 774

not and impressive speedup (only about 2%) :D , but yet

Next thing I will do is to try to get rid of that memcpy(by passing cvm allocated buffer as screen buffer to libcvm), it should give us additional performance boost.

Again, thanks a lot for making this port to maemo and sharing your experience with us.

EDIT:
any chance to PM me a link to download JBenchmark, google finds a site when a registration is needed, but I don't want my inbox full with spam.

Originally Posted by Estel (Post 1185727)

After first batch of optimization, maybe it will be time for extras-devel?

Originally Posted by DavyP (Post 1185731)

JBenchmark:

http://davy.preuveneers.be/phoneme/p...mo/jbenchmark/

Note: only JBenchmark and JBenchmark2 work. The others require
more JSR support

Davy

Originally Posted by freemangordon (Post 1185734)

Thanks a lot.

OK, second optimization pass (memcpy is gone), JBenchmark2 result(same conditions)

landscape - 972
portrait - 804

going to try your benchmarks, will post theresults here.

Originally Posted by DavyP (Post 1185729)

If you would repeat the experiment multiple times, you will notice
that the 2% below is even below the error margin. So I am very
doubtful there is any improvement at all :-)

And about the memcpy: I am pretty sure you will bump into
synchronization issues between two event loops (one of phoneme
and one of the Qt4 frontend). The phoneME backend calls a
method in the Qt4 frontend to say it is time to paint the buffer. The
Qt4 front-end will emit an asynchronous signal. By the time this
signal is processed the original buffer has changed, resulting in
flickering and painting of intermediate frames if you use the
original buffer.

But feel free to experiment, you never know ... :-)

Davy

Originally Posted by DavyP (Post 1185767)

Another remark:

It is possible that the above results are not accurate for another reason. The performance results are measured based on what happens in the event loop of phoneME. This event loop triggers in the Qt4 front-end app a signal emit. So most of what you measure is computation related, not screen IO related. The actual repainting is done in the event-loop of the Qt4 front-end, and it is possible that in this event-loop multiple repaint events are coalesced into a single one (i.e. a single screen update). So the actual painting time in the Qt4 event loop is not included in the benchmark, and the actual screen updates could be lower than what you measure.

Davy

Originally Posted by freemangordon (Post 1185777)

But the same could happen with your code, i.e. there is no check if the current buffer has been painted before doing memcpy over it. And it is less possible to happen without memcpy, as there are 2 screens buffers used by libcvm, against just 1 when memcpy is used. Anyway, i will implement some buffer synchronization, I promise :).

On the other hand both threads are CPU bound, so when there is less overhead (because there is no memcpy for every screen buffer), the computational thread is given more CPU shares to do its job, so I believe the benchmark results are pretty corect.

Originally Posted by DavyP (Post 1185808)

True. I don't check before the memcpy either as I don't want to force paint every frame either if the device cannot keep up.