Re: [compiz] Compiz porting plan, for help
On Tue, 2007-06-12 at 10:33 +0800, Zhu, Jack wrote: > David & All, > > As you might have heard, Intel recently introduced a new low-power > device called a Mobile Internet Device (MID). We're working in > Intel's Open source Technology Center on the Linux Desktop UI. Given > the small screen we're planning on using a stack-based window manager > where each application runs full-screen (think Matchbox). We think it > would be very cool to get a rotation effect like the compiz wm, but > with a single applications per screen. > > Who can give us some suggestion on our Compiz porting plan and give > help on my block issues? I am a newer on Compiz, thank you for all > your help. > > From: Zhu, Jack > Sent: 2007年6月11日 17:11 > To: Shen, Cathy; Spencer, Bob; Zhang, Danny; Li, Horace; Wei, Donald > Subject: status of Compiz > > After investing, I tried the following two methods as Bob’s > suggestions. > > The following is my status: > > Method 1. Just use Matchbox with Compiz feature added. > > Steps: > > 1. Read source code to understand how to use compiz plugins without > compiz windows manager. > > 2. Write a simple application on FC6, call compiz plugin API, to show > effections such as cube, 3D. just link plugin .so file, without > compiz window manager. > > 3. Write two applications, switch to each other, just use compiz > plugins and gnome default window manager: metacity. > > 4. if 3 success, then most likely solution : Metacity with compiz > features added can work > > 5 . if 4 success, then most likely, solution: Matchbox with compiz > features added also can work > > If possible, we can step over 4. direct from 3 to 5. > > Status: still blocked on how to use compiz plugin API in GTK > programs. > > 1. Without doc, It is difficult to understand how to use compiz > plugin, API independently, what’s the parameter means, how to use it > in GTK program. > > 2. Matchbox can add plugins as easily as compiz window manager? Its > design has not consider extensibility to add different plugins easily. > > Probably need write a adaptor layer to connect matchbox window manager > and compiz plugin. > > Method 2. Just try to enable Compiz on MID > > Steps: > > 1. Compile Compiz on MID, install some devel libs. > 2. Run Compiz on MID, install some run time libs > 3. Compiz window manager can manager hildon-applications, port > Compiz window manager from Gnome to Hildon desktop, need much efforts. > > 4. Compiz plugins can work, especially on applications switch. > > Status: still blocked on step 2. > > Run error: > > compiz: No GLXFBConfig for default depth, this isn't going to work. > > compiz: Failed to manage screen: 0 > > compiz: No manageable screens found on display 0:0 > > Root cause: > > 1. Lack some user libs should been installed? > need yum install more libs: Xorg, dri, drm, glx, xgl? Tried to > install all these packages with these key words. > > I installed all the packages of xorg/dri/drm/xgl/ same as FC6, > FC6 can work, but MID can not. > > > 2. Lack some kernel modules? > > xgl depends on kernel module drivers: drm.ko and i915.ko, I > insmod the two modules in MID by hand, Compiz still fails. > > 3. Do not support default depth, default 16 or 24, how to > support it? > 4. Need add or modify configure files? > I add /etc/drirc file as google search’s result. fail > > Modify X11/xorg.conf to add some script to load xgl? fail > > > _ > From: Spencer, Bob s > Sent: 2007年5月25日 10:32 > To: Li, Horace; Zhu, Jack; Wei, Donald > Subject: Matchbox or Compiz? > > > I've been thinking about Compiz vs. Matchbox. I think using Matchbox > wm is faster than using Compiz, but I'm not convinced that is the > right thing to do for the long run. > > Pros / Cons > > If we use Matchbox (w/Compiz feature added) > > - We get all matchbox stuff. No change to Hildon > > - Theming works as designed > > - We have to add compiz code > > - End features: we can rotate applications > > If we use Compiz (w/Matchbox feature added) > > - We have to implement all Matchbox features > > - We have to modify Hildon > > - We have to recreate the themes > > - End features: > > - application rotation > > - show all running apps on single screen > > - magnify screen zoom in/out > - all future compiz features free > > I wonder if Horace can > > - try to get Hildon working on compiz window manager > > - identify all the features that we need to implement in > Compiz to make it behave like Matchbox. > > - stack-based app > > - dialogs behave correctly > > - theming > > - figure out what Hildon code
Re: [compiz] Direct and Indirect: Difference in rendering quality
On Tue, 2007-06-05 at 16:47 -0400, David Reveman wrote: > On Tue, 2007-06-05 at 18:01 +0100, Matt Russell wrote: > > Hi > > > > Why is the quality of scaled textures/objects using --indirect-rendering > > much worse than direct rendering? Also, vsync does not work with > > indirect-rendering. > > Scaled texture quality problem might be caused by > GLX_EXT_framebuffer_object extension not being supported when using > indirect rendering. This means that mipmap filter can't be used with > pixmaps bound to textures. > > GLX_SGI_video_sync extensions is used for vsync and that extension will > only work properly with direct rendering. > > -David > That's a shame - performance for me is better using indirect rendering (for most things at least), although I'm sure a few months ago compiz ran better with direct rendering... Matt ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Direct and Indirect: Difference in rendering quality
Hi Why is the quality of scaled textures/objects using --indirect-rendering much worse than direct rendering? Also, vsync does not work with indirect-rendering. I am using an Nvidia Geforce go 7300, with 97.55 drivers. Thanks, Matt ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] adding XCB dependency
On Fri, 2007-04-27 at 18:13 +0200, Danny Baumann wrote: > Hi, > > > I intend to make compiz depend on XCB and Xlib/XCB sometime soon so we > > can start using XCB where it's beneficial [1]. I'm mostly interested in > > using it for asynchronous reading of window properties but we should > > eventually try to use it for as much as possible. Removing Xlib > > completely might not make sense as we need to support multiple > > implementations of GLX but getting to a stage where it's possible to > > disable Xlib at build time for those who are interested in that would be > > neat. > > > > If you've got any issues with XCB and Xlib/XCB being added as > > dependencies please speak up asap. Thanks. > > Just for curiousity - which distros do actually ship XCB at the moment, > at least as some sort of extra/unofficial package? I couldn't find one > at the moment for my distro (FC6/F7) and I doubt many people (as in: > users of compiz) want to compile XCB and Xlib/XCB manually. > Does anyone of you know when XCB will be included in all major > distributions? > > Regards, > > Danny > > ___ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz XCB is included in the official repository in Ubuntu Feisty, but not installed by default. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Resize improvements (Multiple resize modes, better aspect ratio constraining)
So is the poor resize performance seen on Nvidia cards caused by the drivers and not compiz? On Thu, 2007-04-19 at 12:38 -0400, David Reveman wrote: > On Thu, 2007-04-19 at 09:41 +0100, Colin Guthrie wrote: > > Anders Storsveen wrote: > > > how can vista resizing and redrawing be so fast, while compiz and osx' > > > resizing is slow? as I understand it, vista also uses composition in > > > their aero-glass stuff too. > > > > > > > > Seems pretty fast resizing here? Can you be more descriptive? Do you > > mean on certain applications adapting to the resized space and changing > > their layout accordingly (e.g. a webpage in Firefox) or do you mean > > literally the resizing part (that part which compiz does)? > > Compiz has very little to do with resize performance. It's all about > offscreen memory management and how fast applications can redraw. Any > alternative resize modes that compiz might use like stretching is only > ways to avoid resizing. > > There's server side changes that can be made to improve resize > performance but not much that can be done in compiz itself. > > btw, if you've been able to use the video plugin and the video interface > I added recently you'll see how good resize performance you can get when > the server and application doesn't have to be involved. > > - David > > ___ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Resize improvements (Multiple resize modes, better aspect ratio constraining)
I think on some hardware resizing is much slower than to others. For example, with an Nvidia Geforce 6800 resizing is painfully slow (driver bug?) but with an old Radeon 9600 with the OSS drivers, resizing is as fluid as Metacity. I hope this issue is resolved soon, though I'm not sure what is causing it... Regards, Matt On Wed, 2007-04-18 at 16:44 +0200, Anders Storsveen wrote: > how can vista resizing and redrawing be so fast, while compiz and > osx' resizing is slow? as I understand it, vista also uses > composition in their aero-glass stuff too. > > Den 18. apr. 2007 kl. 10.45 skrev Danny Baumann: > > > Hi, > > > >> I have ported various improvements of Beryl's resize to Compiz: > >> > >> - multiple resize modes (aside to the standard "normal" mode those > >> are > >> "Stretch", "Outline" and "Filled Outline") > >> - better aspect ratio constraining (you now also can resize aspect > >> constrained windows from other edges than the lower right) > >> - avoiding of mouse pointer desynchronization when the resizing hit > >> constraints. > >> > >> While porting this, I cleaned up the code and fixed some performance > >> problems, so the code is supposed to work without problems. > >> > >> If you want to use the new options and are using gconf, you have > >> to do > >> 'make compiz.schemas.in' in your plugin directory to update the > >> schema > >> file. > >> > >> Please tell me what you think of that patch and if you experience any > >> problems while using it. > > > > I've splitted up the patch into several smaller ones, adapted them for > > latest API changes and fixed some minor bugs which I got reported. > > > > Some more feedback would still be nice :-) > > > > David, are there any objections against including this code? > > > > Regards, > > > > Danny > > <0001-Added-options-for-additional-resize-modes.patch> > > <0002-Added-painting-code-for-additional-resize-modes.patch> > > <0003-Update-resize-logic-to-reflect-additional-resize-mod.patch> > > <0004-Added-proper-constraining-code.patch> > > <0005-Warp-pointer-if-resizing-hit-constraints-to-avoid-mo.patch> > > <0006-Added-screen-damages-which-were-missing-if-the-resiz.patch> > > <0007-Avoid-resizing-windows-to-negative-sizes.patch> > > <0008-Avoid-window-flashing-back-to-its-old-size-for-a-sho.patch> > > ___ > > compiz mailing list > > compiz@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/compiz > > ___ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
