View Single Post
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#516
Originally Posted by DavyP View Post
Yes, but I have not come around to integrate your changes into my build.

I noticed that you removed the static buffer in which I copied all the pixels from the original framebuffer pointer when phoneME tells me to draw the buffer. My code relied on this buffer when I emited a Qt4 signal to draw the buffer.

You pass along the original pointer directly to the Qt4 front-end. Using the original pointer is a bit dangerous. By the time the refresh signal gets processed and the buffer gets painted, the contents and the size of the original framebuffer pointer may have changed, causing bad repaints or even segmentation faults. This has to do with the inner workings of phoneME, and the asynchronous handling of Qt4 signals.

Before, I actually implemented it more or less the way you did it (without the static buffer), and I got segmentation crashes when I was playing some animation (continuous repaints) while changing the display size (going full screen).

I will first do some testing to see whether your code suffers from the same problem before integrating your changes in my latest code.

Cheers,
Davy
Hmm, but I actually don't allow phoneME to draw to a buffer which is still in use by Qt. Have in mind that we have TWO buffers used in sequence. And there is a (lame) spinlock protecting currently used buffer, look

here: https://gitorious.org/cvm-qt/cvm/blo...in.cpp#line139

and here: https://gitorious.org/cvm-qt/cvm/blo...er.cpp#line162

That way when a new buffer needs to be painted, we don't return control to PhoneME until the old one is still painted by Qt, preventing PhoneME from using it . Sure, this synchronization could be implemented without the overhead of using QMap, but as POC it should be good enough.
 

The Following User Says Thank You to freemangordon For This Useful Post: