On Fri, 2010-10-22 at 09:20 +0800, ext Feng, Haitao wrote: > 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?
Yes (at least currently) logic is to composite only when *really* needed, otherwise let application (as it is fullscreen sized) use direct rendering for best possible performance. > 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 _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
