> Message: 5 > From: "Michael E. Peligro" <[EMAIL PROTECTED]> > Organization: Abbey Road Recording Studios > To: [EMAIL PROTECTED] > Subject: Re: [plug] ckolivas patches > Date: Sat, 21 Sep 2002 17:37:59 +0800 > Reply-To: [EMAIL PROTECTED] > > On Wednesday 18 September 2002 04:25 pm, you wrote: > > > I patched the vanilla 2.4.18 source that came > > with Slackware 8.1 to 2.4.19 and then applied > > Con Kolivas' patchset > > (http://members.optusnet.com.au/ckolivas/kernel/ck7_2.4.19.patch.bz2). > > The result was pretty amazing. The KDE windows > > now move around like greased lightning! > > I'm also curious if KDE will also move like this on an AMD-K6-500 128 MB RAM > with 8MB SIS530 graphics card, given the same kernel and patchset? Did Con > Kolivas try his kernel-patchset combo on a low-end machine? I'm curious if > KDE can finally be operable in low-end machines such as Pentium I's and II's. > I have several friends who use Gnome on these low-end machines because Gnome > is much faster. Personally, I prefer KDE because of its more consistent > user-interface and behavior. The only problem is that KDE's slow on these > machines.
Turns out the celebration was premature. I went back to 2.4.18 and guess what... KDE windows still moved around like greased lightning (even on the ancient Voodoo 3 2000) - so the LL/PE/O(1) patches weren't responsible for it. IN ADDITION, the patch did nothing for OpenGL/graphics latency. The behaviour of xmms' OpenGL spectrum analyzer was the same under 2.4.18 and 2.4.19 with the ckolivas patches. The animation stutters badly when you move a window around. Experiments with renicing different threads accomplished nothing 'cept to make things even less responsive. Disappointing... Not sure if this is due to the way XFree works (no pervasive multithreading) or the patches simply aren't effective. > > Time to do some low-level Linux gfx/audio programming > > and see how the the preemptable, low-latency, O(1) > > scheduled kernel stacks up to WinXP and BeOS. > > My friends and I noted that the game sounds considerably lagged while playing > Unreal Tournament 2003 on Linux with Athlon motherboards and Nvidia chipsets > (rocket-firing sounds are heard a moment after they're seen firing onscreen > :-( ). Any tip(s) on what seems to be the problem? > > By the way, Unreal Tournament 2003 on Linux looks gorgeous, much like "Halo" > on Xbox. :-) > > Can the preemptable, low-latency, O(1) scheduled kernel reduce MIDI latency > timing problems? In theory it should. It's more the Linux audio enthusiasts than the gfx people that are into the LL patches. > > The Linux framebuffer abstraction is great! It gives > > game programmers a standard, solid gfx API besides > > svgalib and X (pleh...). > > Hope this technology is a major step in creating a DirectX-like graphic > technology for Linux machines. Will it? What advantage(s) will it give to > SDL? The Linux framebuffer is a low-level abstraction of the gfx hardware (or VESA 2.0) that provides programs uniform access to linear video memory. DirectFB attempts to provide a more full-featured API that also covers 2D acceleration. A Linux framebuffer/DirectFB driver for SDL means that SDL programs can work without having to run under X or use svgalib (which has been long in the tooth for quite a while now). GGI/KGI is an alternative to the Linux Framebuffer/DirectFB but it's the latter which seems to have been blessed by Linus for inclusion in the stock kernel. _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
