Re: Live Splitview patch
Hi, > I actually wrote the feature on a netbook... > Personally I think it's the _right_ way -- the xor splitview is imho > just a hack (and OSX is of course using live resizing). Now, doing > live resize may expose some slowness in -gui, but instead of fighting > the messenger we should fix it. > That being said, it's imho fast enough as it is now. That's fine then. I would add it as a global variable to enable/it disable it. The same way live window resizing should have. Even on the mac you can disable several effects (for example with small tools). This is very useful also for remote display. Under windows, if you use RDP to access your terminal, depending on the connection, many features get disabled: shadows under the cursor, funky progressive display menus, shadows under the menus and so on. All those things have keys in the registry (which any speed-up software can tweak for you). Our version of the registry is the defaults system. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Live Splitview patch
On May 15, 2009, at 10:49 AM, Wolfgang Lux wrote: In order to keep Riccardo happy you might introduce a new user default to switch between live and non-live resize. However, given that the changes appear quite substantial upon a superficial look, I don't know whether this is feasible. I would concur with Wolfgang that, if this behavior is optional, it would best be controlled by a user default rather than by some dynamic test (timing of operations, etc.) Different people have different thresholds of tolerance for "slow" behavior; an automatic test is unlikely to satisfy as many people as a simple choice might. The fastest "PC" I have in service right now is a 200MHz PIII. It is "fast enough" for the few things I use it for, and I don't like generic PC hardware enough to justify the effort or time needed to upgrade it yet. I use my MacBook or Sun workstation for most things. If it were possible to turn this feature off, I would turn it off on both the PC and the Sun (which is a dual-processor Sparc, but only 450MHz, and enormously slower in X than I am comfortable with since I installed Solaris 10 on it). --Robert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Live Splitview patch
I really believe we should go ahead and put this change in and see what the actual impact on some systems is before dismissing it out of hand. If it becomes an efficiency issue we can make it conditional on some machines or make it a default. On Thursday, May 14, 2009, David Chisnall wrote: > Running this in my VM, with remote X11, there is slight lag (as I'd expect > from remote X11) and resizing the splitview makes my CPU usage jump to a > massive 1.9%. > > I realise that this is a massive overhead, and suggest that we consider very > carefully whether it is worth the extra cost. > > David > > On 14 May 2009, at 21:49, Riccardo Mottola wrote: > > > Hmm, > > I prefer not to have them live... it disturbs me. > Besides, 1ghz is slow for a desktop perhaps, but for some netbook it is not. > > --Riccardo > > > > Hi, > > I'm ready to commit this patch, but I wanted to give the heads up > > before... > > This basically remove the reverse splitview bar we draw to instead do > live resizing. > It's reasonably fast, tested on slow-ish machines (~1ghz x86 & ppc), > and makes things much nicer from a UI point of view. > Comments before I submit ? :) > > > > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Live Splitview patch
Nicolas Roard wrote: I'm ready to commit this patch, but I wanted to give the heads up before... This basically remove the reverse splitview bar we draw to instead do live resizing. It's reasonably fast, tested on slow-ish machines (~1ghz x86 & ppc), and makes things much nicer from a UI point of view. Comments before I submit ? :) In contrast to Riccardo I prefer having live resize and I like your patch. I've just tested it on my old 550MHz PowerBook running GNUstep on OS X and it is a bit sluggish there, but I find it still usable -- at least with the art backend. The xlib backend seems to be worse in this respect. (Unfortunately, I can't test the cairo backend on that machine). In order to keep Riccardo happy you might introduce a new user default to switch between live and non-live resize. However, given that the changes appear quite substantial upon a superficial look, I don't know whether this is feasible. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Live Splitview patch (and a brief touch on live window resizing)
Am 14.05.2009 um 23:08 schrieb Gregory Casamento: It would be nice to have some modern features such as this. +1 [...] make it conditional [...] I'd resist to make the code more complex than neccessary. All you can gain are complaints about different behaviour in different situations (cpu speed, system load). Mac OS X handles live resizing on a 132 MHz machine under full steam still fine - even if it isn't exactly "live", then. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
