Thread: [BETA RELEASE] PhoneME Advanced (Java Mobile)
View Single Post
freemangordon is offline freemangordon
2012-04-10 , 17:30
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#518
Originally Posted by DavyP View Post
You are right. I did not notice the usleep() you use to synchronize between both event loops. You indeed do not need a QMap to synchronize (a dirty flag will do).
Absolutely, it could be optimized further, but as I told you that was just a POC and I was lazy to use/implement atomic integer operations or to read through the net if operations on u32 type are atomic on ARM7 .

The pointer passed along to repaintPixmap() is often the same anyhow.
Disagree, framebuffer frontend uses backbuffering, i.e. two buffers used for consecutive painting. BTW i had put some qDebug() in repaintPixmap and can assure you, that those two buffers are rotated, i.e. you never have one and the same pointer for two consecutive repaintPixmap calls.

Also, I wonder if you could speed things up by waiting a bit longer than usleep(1), i.e. 1 microsecond. I don't know how fine-grained the N900's default timer resolution is, but if it would be that accurate, you are spending a lot of CPU with busy waiting. I think somewhere between 1 to 10 milliseconds (or 1000 to 10000 microseconds) might improves things as you sleep longer per iteration, leaving more time for the other threads to complete the repainting. I have not tested this though, as you would have to count how often you execute the cycle in a benchmark setup (where you try to paint as fast as possible).

Cheers,
Davy
Yeah, I was thinking the same, a proposed delay should be pretty enough.
 

The Following 2 Users Say Thank You to freemangordon For This Useful Post: