From: Steve C. <ste...@is...> - 2002-11-21 21:24:17
|
Hi, I did a quick search for this topic in the FAQ and the archives, and saw nothing. I run fluxbox on pretty high end optimized hardware. When I run the Rox pinboard, even without a background image, it slows down drag-moving windows drastically. I'm using a full window drag (not an outline). The window movement becomes very slow and unresponsive, as if it's not bit blt'ing the window, but doing a full repaint for each slight shift. Could there be some window property that's not being set (or being set) by Rox that causes a full repaint of moving windows? Maybe something with the backing store? These are just words to me. But I'm hoping to fire somebody else's neurons. :-) This is the only thing stopping me from integrating the pinboard with fluxbox as a desktop manager. I'm already extremely pleased with the panel's coexistence with fluxbox. Cheers, Steve -- \_O< \_O< \_O< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Cooper Redmond, WA |
From: George De B. <Sou...@my...> - 2002-11-22 05:59:15
|
On Thu, 21 Nov 2002 13:23:15 -0800 Steve Cooper <ste...@is...> wrote: > I run fluxbox on pretty high end optimized hardware. When I run the > Rox pinboard, even without a background image, it slows down > drag-moving windows drastically. I'm using a full window drag (not an > outline). Hi Steve, I run Rox with FluxBox here too, and see the same problem. However, I suspect that this *may* not be an issue that is specifically a Rox issue. I've also played with Rox with several other window managers, and as far as I can tell Flux is the only one to exhibit this behavior. From a simple test here, I just turned off the tabs in Flux and tried dragging a window. It was a lot faster than with the tabs turned on. So, if I am to be allowed a little speculation, I think there is something between the interaction of Rox's panel, and Flux's tabs that are causing most of the issue. Alas, I have been unable to completely quantify the problem so I haven't mentioned it before now... // George |
From: Steve C. <ste...@is...> - 2002-11-22 06:39:03
|
From George De Bruin <Sou...@my...>, on Thu, Nov 21, 2002 at 11:46:48PM -0600: > On Thu, 21 Nov 2002 13:23:15 -0800 > Steve Cooper <ste...@is...> wrote: > > > I run fluxbox on pretty high end optimized hardware. When I run the > > Rox pinboard, even without a background image, it slows down > > drag-moving windows drastically. I'm using a full window drag (not an > > outline). > > Hi Steve, > > I run Rox with FluxBox here too, and see the same problem. However, I > suspect that this *may* not be an issue that is specifically a Rox > issue. I've also played with Rox with several other window managers, > and as far as I can tell Flux is the only one to exhibit this > behavior. > > >From a simple test here, I just turned off the tabs in Flux and tried > dragging a window. It was a lot faster than with the tabs turned on. > So, if I am to be allowed a little speculation, I think there is > something between the interaction of Rox's panel, and Flux's tabs that > are causing most of the issue. > > Alas, I have been unable to completely quantify the problem so I > haven't mentioned it before now... > > // George > ---end quoted text--- Thanks for replying. At least I'm not crazy (about this)! :-) I'll look into filing a bug against fluxbox. I'll also see if I can find a pattern with the tabs on or off, or anything else. Makes sense to look at tabs, if the problem is unique to fluxbox. I have seen other applications cause the same effect when windows are dragged in front of them under fluxbox. It also may have something to do with the pseudo-transparent terminal I'm using. But it works fine normally. Regards, Steve -- \_O< \_O< \_O< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Cooper Redmond, WA |
From: Thomas L. <ta...@ec...> - 2002-11-22 11:27:19
|
On Thu, Nov 21, 2002 at 01:23:15PM -0800, Steve Cooper wrote: > Hi, > > I did a quick search for this topic in the FAQ and the archives, and > saw nothing. > > I run fluxbox on pretty high end optimized hardware. When I run the > Rox pinboard, even without a background image, it slows down > drag-moving windows drastically. I'm using a full window drag (not an > outline). > The window movement becomes very slow and unresponsive, as if it's not > bit blt'ing the window, but doing a full repaint for each slight > shift. Could there be some window property that's not being set (or > being set) by Rox that causes a full repaint of moving windows? Maybe > something with the backing store? These are just words to me. But > I'm hoping to fire somebody else's neurons. :-) First of all, try enlarging some other Gtk+-2.0 window to fill the screen (eg, a normal ROX-Filer window) and try dragging something across that. If that's slow, the problem is likely to be at the Gtk level. The pinboard redraw is double-buffered (like all redraw in Gtk+-2.0), which might be a little slow for some video cards. It may be possible to optimise this (see /* TODO: Split large regions into smaller chunks... */ in pinboard.c). However, it's very fast for me, so I can't really see what helps or what's causing the problem specifically. Someone else will have to send a patch if that's the problem... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: George De B. <Sou...@my...> - 2002-11-22 16:30:02
|
On Fri, 22 Nov 2002 11:23:33 +0000 Thomas Leonard <ta...@ec...> wrote: > First of all, try enlarging some other Gtk+-2.0 window to fill the screen > (eg, a normal ROX-Filer window) and try dragging something across that. If > that's slow, the problem is likely to be at the Gtk level. Hi Thomas, Since I noted that I can see the same (or at least very similar) issue I tried this. Even with a standard GTK+ window maximized moving a window in Fluxbox was very slow with the tabs turned on, but with tabs turned off it is much more responsive. Additionally, this does seem to only be an issue when "Opaque window moving" is turned on. With this off, the whole issue appeared to disappear completely. I think this comes down to a need for the Flux guys to work on doing some optimizing in their tab / window group handling code. It appears they need to look at the window group, and window tabs and finding a more optimized way to update the position of multiple windows/tabs simultaneously when opaque moving is turned on. FYI, on a seperate but notably related issue, Fluxbox 0.1.13 has implemented the following: _NET_WM_DESKTOP, _NET_NUMBER_OF_DESKTOPS, _NET_CURRENT_DESKTOP, _NET_ACTIVE_WINDOW, _NET_CLOSE_WINDOW, _NET_WM_STATE, _NET_WM_STATE_STICKY, _NET_WM_STATE_SHADED Maybe someone else can comment on this portion of the flux code. I don't have GTK+-2.0 here so I am not using this support. // George |
From: Steve C. <ste...@is...> - 2002-11-23 05:15:37
|
From George De Bruin <Sou...@my...>, on Fri, Nov 22, 2002 at 10:17:29AM -0600: > Since I noted that I can see the same (or at least very similar) > issue I tried this. Even with a standard GTK+ window maximized moving > a window in Fluxbox was very slow with the tabs turned on, but with > tabs turned off it is much more responsive. I experienced the same thing. Suprisingly, even an xcalc (not GTK) maximized causes the same problem with fluxbox. Seems anything but the normal root window can be the trigger. There must be special handling of the root. FWIW Rox imposes no worse performance penalty than any other full-screen window. :-) Disabling tabs doubles the performance (approx.) for me. But it doesn't bring it close to the performance of a tabbed window on the normal root window background. > Additionally, this does seem to only be an issue when "Opaque window > moving" is turned on. With this off, the whole issue appeared to > disappear completely. To expand on this... AFAIK Non-opaque (outlined) window moving just inverts pixels under the outline. It doesn't force anything to repaint. No window manager should have any performance issues with outline dragging (IMO). Hope I'm not just hammering the obvious. Of course to compound things I was using pseudo-transparent terminals. On my hardware, disabling pseudo-transparency was enough to make the pinboard an acceptable backdrop. With the tabs off it's pretty decent. I was getting retinal cavities from all the eye candy anyway. :-) <snip> > FYI, on a seperate but notably related issue, Fluxbox 0.1.13 has > implemented the following: > > _NET_WM_DESKTOP, > _NET_NUMBER_OF_DESKTOPS, > _NET_CURRENT_DESKTOP, > _NET_ACTIVE_WINDOW, > _NET_CLOSE_WINDOW, > _NET_WM_STATE, > _NET_WM_STATE_STICKY, > _NET_WM_STATE_SHADED > > Maybe someone else can comment on this portion of the flux code. I don't > have GTK+-2.0 here so I am not using this support. I'm moderately familiar with the code, but I'm not sure what kind of information you're looking for. How do you plan on using these properties? I appreciate all the quick responses. Rox is definitely growing on me. :-) Cheers, Steve -- \_O< \_O< \_O< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Steve Cooper Redmond, WA |
From: George De B. <Sou...@my...> - 2002-11-24 08:33:31
|
On Fri, 22 Nov 2002 21:15:14 -0800 Steve Cooper <ste...@is...> wrote: > Disabling tabs doubles the performance (approx.) for me. But it > doesn't bring it close to the performance of a tabbed window on the > normal root window background. Hmmm, I never thought about this, but I wonder if Flux is treating Rox's root window as a tabbed window, but the tab is actually off screen.... I made a mental note some time back that if I grouped two Galeon windows together, then went to full screen mode, the windows were still grouped, but their tabs were off screen. (IE, I could switch between them using my key binding for flux's NextTab and PrevTab commands...) > repaint. No window manager should have any performance issues with > outline dragging (IMO). Hope I'm not just hammering the obvious. True enough - and I knew this... However, explicitly testing things that should be obvious sometimes turns up interesting issues. :) > On my hardware, disabling pseudo-transparency was enough to make the > pinboard an acceptable backdrop. With the tabs off it's pretty > decent. I was getting retinal cavities from all the eye candy anyway. > :-) I've found that some of these little "neat" features tend to have a high price in terms of overhead. So I tend to try them out, see what the price is, and see if there is a specific need for them. If there isn't, I turn them off. Having tabs in the window manager is one of the few things that I've found to be so useful that I am willing to pay the overhead price for it. I tend to get easily distracted with too much eye candy, so I try to pick and chose carefully...:) Comfort is necessary in a user interface, opulence isn't, IMO. :) > I'm moderately familiar with the code, but I'm not sure what kind of > information you're looking for. How do you plan on using these > properties? Sorry, wasn't actually looking for anything... Accidentally posted to the wrong list. I was just mentioning it because Thomas had been looking at some issues related to netwm implementation in other window managers. I thought if anyone else had upgraded to the new version of Flux they might be able to comment if they had seen any of the issues that Thomas has been working with. > I appreciate all the quick responses. Rox is definitely growing on > me. :-) It grew on me about 5 minutes after I got it installed. // George |
From: Matthew W. O. <wei...@gr...> - 2002-11-23 19:42:41
|
-- George De Bruin <Sou...@my...> wrote (on Friday, 22 November 2002, 10:17 AM -0600): > FYI, on a seperate but notably related issue, Fluxbox 0.1.13 has > implemented the following: > > _NET_WM_DESKTOP, > _NET_NUMBER_OF_DESKTOPS, > _NET_CURRENT_DESKTOP, > _NET_ACTIVE_WINDOW, > _NET_CLOSE_WINDOW, > _NET_WM_STATE, > _NET_WM_STATE_STICKY, > _NET_WM_STATE_SHADED > > Maybe someone else can comment on this portion of the flux code. I don't > have GTK+-2.0 here so I am not using this support. This code is to comply with ICCWM or netwm support -- which is being used by window managers to have standard window hints regardless of toolkit, etc. (Thomas, elaborate if I don't have the full picture). Blackbox is rolling out netwm support for the 0.70 release, openbox has partial netwm support already, so this looks like fluxbox is now grabbing the current netwm support from the blackbox cvs. It doesn't have anything to do with GTK+ (other than GTK+ will utilize it -- and I think the 1.x series already was moving in that direction anyways) so much as the window manager and how it handles and reports certain window states. Basically, this means that features like the rox pager will start working in fluxbox (as will the kde or gnome pagers) -- among other things. -- Matthew Weier O'Phinney ma...@we... |
From: George De B. <Sou...@my...> - 2002-11-24 08:05:52
|
On Sat, 23 Nov 2002 14:42:23 -0500 Matthew Weier OPhinney <wei...@gr...> wrote: > > FYI, on a seperate but notably related issue, Fluxbox 0.1.13 has > > implemented the following: > > > > _NET_WM_DESKTOP, > > > > Maybe someone else can comment on this portion of the flux code. I don't > > have GTK+-2.0 here so I am not using this support. First a whoops: I thought I was posting on the dev list...:) I'll cross-post this message to devel since that's where I intended it to be in the first place...:) > This code is to comply with ICCWM or netwm support -- which is being > used by window managers to have standard window hints regardless of Right. The reason that I mentioned it was that Thomas was looking at a couple of issues that appear to be related to the implementation of netwm in other window managers. > partial netwm support already, so this looks like fluxbox is now > grabbing the current netwm support from the blackbox cvs. I don't think they are.... Going through their change log specifically notes when they started implementing netwm support, and what changes have been made along the way... Doesn't sound like they're merging code (but, I could be wrong...without comparing the two code bases, or having some other confirmation/denial it would be difficult to be certain). > It doesn't have anything to do with GTK+ (other than GTK+ will utilize > it -- and I think the 1.x series already was moving in that direction > anyways) so much as the window manager and how it handles and reports > certain window states. > > Basically, this means that features like the rox pager will start > working in fluxbox (as will the kde or gnome pagers) -- among other > things. Right - the reason I mentioned not having GTK+-2.0 is that I can't play with the newer versions of Rox that are utilizing the netwm support and need GTK+ 2 to compile. :) // George |