[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Regarding KDE 4
From:       Zack Rusin <zack () kde ! org>
Date:       2004-07-03 8:06:47
Message-ID: 200407030406.49111.zack () kde ! org
[Download RAW message or body]

On Friday 02 July 2004 23:27, Damien Uern wrote:
> Unfortunately the problem with IO-Slaves is that they work for KDE
> applications only. It would be better to use LUFS and actually have a
> fish:// mount point on the system so that any old app can use it. The
> problem comes with cross-platform capabilities. fish:// works great
> on my Solaris box at University, but if it depended on LUFS it
> obviously wouldn't. Perhaps optional LUFS support at
> compile-time/runtime would be needed.

We already have it. fuse-kio

> One of the other cool things coming with QT4 is Cairo support. It

It is not certain Qt 4 will have Cairo Aurthur backend.

> should be possible to have some cool animations and effects (and true
> translucency) because of the ability to render with OpenGL as the 
> backend. 

That's just plain wrong.
1) Translucency has nothing to do with Cairo or OpenGL.
2) Qt 4 will have support for translucency.
3) Cairo with Glitz backend doesn't expose animation and we can't depend 
on one backned therefore those "cool animations" would have to deal 
without OpenGL in its main rendering.

> Even without OpenGL support, with new features going into 
> Xorg, rendering will hopefully be better with no tearing/slow
> redraws, etc...

Who said X redraws are slow? In fact, as it is - Cairo is slow. It's 
very slow. The number of drivers accelerating Render is very limited. 
The number of drivers with decent OpenGL acceleration to handle the 
Glitz backend is also very small.

I'm sure you wanted to be helpful and thanks for the interest but you're 
spreading misinformations so please watch it.

Zack

-- 
Tact is the ability to tell a man he has an open mind when he
has a hole in his head.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]