Hi Abdiel, Thank you very much for your reply!
I get the mcompositor source code by "zypper si meegotouch-compositor" after extracting the MeeGo 10-15 handset image and chrooting into it. The version is 0.5.8 and the mcompositemanager.cpp is attached. This is the code base I will be working for. I am the developer to run MeeGo UX inside Xephyr or Qemu with GL acceleration, as mcompositor sometimes crashes in Xephyr or Qemu, I am trying to find out whether it is our code's bug or mcompositor's bug. Because of your surprise, I checked out your git repo at http://www.meego.gitorious.org/meegotouch/meegotouch-compositor. The git codes are quite newer than 0.5.8. Mcompositemanagerextension, mcompositewindowshadereffect and loadPlugin are all not in 0.5.8. But for possiblyUnredirectTopmostWindow, our question still applied, it seems that "if (w == stack[DESKTOP_LAYER])" has the same effect as "cw->isMapped() && cw->isAppWindow(true)". I am interested with alternative 1, as you said, "Application windows do not need to be composited all the time. Native meegotouch applications draw their own window decorations and borders and do not need the decorator from the compositor." Yes, the fullscreen application, such as video player or high-speed games, do not need to be composited as the performance might not be good enough. Are the meegotouch applications all belongs to this category? Yongsheng is interested with alternative 2, as you said, "Decorator is for 3rd party apps such as games that do not use the meegotouch framework." Our question is that: Why draw their texture into compositor's GL window instead of draw them directly and unmap the overlay as you did for meegotouch applications when animation is finished? Robert has suggested that maybe for 3rd party apps, you want to give them some window effect, such as fog, while meegotouch applications do not need or already have the window effect. Is it the answer for "mcompositor's compositing functionality depend on the type of the topmost window"? Thanks -Haitao On Thu, Oct 21, 2010 at 09:40:58PM +0800, Abdiel Janulgue wrote: > > The difference here is whether the app window is MTF-based. If it's an app > > of non-MTF based, the composite overlay will be shown for animation and > > composite decorator and app window. But if it's a MTF-based window, > > composite overlay is only for animation from my understanding. I think > > it's because of performance concern. Could Anyone who knows about it tell > > us the root cause? > > I don't completely get what you're trying to say here. The overlay is always > needed whenever composition use case is triggered - whether it is needed for > animating the windows or for using the decorator. For all other use case, > each > window should be rendering directly to the framebuffer. > > -abdiel > > > > > Cheers, > > Yongsheng > > > > > -----Original Message----- > > > From: Ohly, Patrick > > > Sent: Thursday, October 21, 2010 8:37 PM > > > To: Feng, Haitao > > > Cc: [email protected]; Zhu, Yongsheng; MeeGo Touch > > > Development > > > Subject: Re: [MeeGo-dev] Why does the mcompositor's > > > compositing functionality depend on the type of the topmost > > > window? > > > > > > Hello Haitao! > > > > > > You might have a better chance getting an answer to the > > > email below on > > > the MTF mailing list. On CC and Reply-To set. > > > > > > On Do, 2010-10-21 at 11:29 +0100, Feng, Haitao wrote: > > > > Dear mcompositor developers, > > > > > > > > Yongsheng and I have a question on mcompositor, why does > > > > > > the compositing > > > > > > > functionality depend on the type of the topmost window? > > > > > > > > The function > > > > > > MCompositeManagerPrivate::possiblyUnredirectTopmostWin > > > dow() will > > > > > > > judge whether the topmost root window isAppWindow(true), > > > > > > if it is true, it will > > > > > > > not do the compositing. Otherwise it will do the compositing > > > > > > which means it will > > > > > > > get the texture of the topmost window, combine the > > > > > > decorator texture and draw > > > > > > > them into full screen on mcompositor's GL window. > > > > > > > > Comparing the below two alternative coding logics: > > > > 1. If it is AppWindow, draw the AppWindow's texture > > > > > > on compositor's GL > > > > > > > window. This means mcompositor's GL window will be > > > > > > always mapped. > > > > > > > 2. If it is not AppWindow, combine it with decorator > > > > > > directly and do not touch > > > > > > > texture staff. This means mcompositor is only used for > > > > > > window animation. > > > > > > > Is there any special consideration on this design logic? > > > > > > > > Thanks > > > > -Haitao > > > > _______________________________________________ > > > > MeeGo-dev mailing list > > > > [email protected] > > > > http://lists.meego.com/listinfo/meego-dev > > > > > > -- > > > Best Regards, Patrick Ohly > > > > > > The content of this message is my personal opinion only and > > > although > > > I am an employee of Intel, the statements I make here in no > > > way > > > represent Intel's position on the issue, nor am I authorized to > > > speak > > > on behalf of Intel on this matter. > > > > _______________________________________________ > > MeeGo-dev mailing list > > [email protected] > > http://lists.meego.com/listinfo/meego-dev > > _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
