(I have all your other mails queued up to read again and reply to, but I'd like to reply to this one as quickly as possible.)
On Thu, May 03, 2007 at 12:39:11PM +0300, ext Siarhei Siamashka wrote: > On 5/3/07, Eero Tamminen <[EMAIL PROTECTED]> wrote: > >Same problem as using framebuffer directly. How user switches > >to another application? How to invoke power menu properly etc. > > What problem with using framebuffer directly? Everything should be > fine, you can get notifications from xserver when your window becomes > obscured, so you can stop drawing. I suggest you to try MPlayer on > Nokia 770 to check how it interacts with xserver. The worst thing that > can happen is some garbage data left on screen on fast applications > switching. That can happen because there is no support to synchronize > access to framebuffer in a reliable way (application using framebuffer > directly may get notification from the xserver about getting inactive > too late and overwrite some other application window). Behold, the problem. Also bear in mind that the X server is perfectly within its rights to change the framebuffer setup, layout, and dimensions, and you won't have any idea. > Adding support to xserver for proper synchronization with direct > framebuffer access applications should be quite possible. It already > synchronizes access to framebuffer with DSP (Xsp API for registering > DSP area). Almost all the necessary changes will probably have to be > added at the same places in xserver which support interaction with > DSP. This will _never_ be added. I think you're basically microoptimising at this point. If someone can show that our primary performance bottleneck is app -> server -> framebuffer (and that it's not just caused by naive use of the X libraries, which is generally the case), then sure, we've got something to work with there. But I don't see that this is at all the case. All we're adding is unnecessary complications and layering violations. Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
