Qt-interest Archive, February 2001
QT/Emb, KPE, OpenGL and The End of X
Message 1 in thread
QT Wizards:
This has probably been discussed at some length before I arrived
on the list, but I had this vision....
(1) We know that QT/Emb is a cool product with anti-aliased fonts,
high-speed rendering, alpha blending and its GPL'ed. (as soon as I
resolve the bug in getting it working on my framebuf I'm sure it will be
even more fun -- hang in there Martin).
(2) Our old friend, the X window system is getting a bit long in the
tooth. The amount of extra baggage in X versus the frequency of use
of those features (network transparency mostly) doesn't seem to
justify the performance and memory hits we take everytime we render.
There is nothing in X that I wouldn't be willing to do under VNC
when I actually need that functionality.
(3) Since most QT and KDE apps are an easy recompile away from
working on QT/Embedded, why are we still using X?
(4) Since fbcon runs as a kernel hack is there any way we can
make sure that bugs in the framebuffer drivers/accelerators dont
compromise the stability of our Linux systems?
(5) Is there any way to convert accelerated 3D drivers under X
so that they work under a KDE/QT OpenGL framework?
The result of all this would be an excellent 2D/3D accelerated
environment for Linux that would be a natural platform for
game development. At that point we would bid X Window a fond
adieu. Thoughts on the matter? (let the fur and flames fly)
What would it look like? An RPM for KPE (K Pocket Edition),
QT/Emb and hardware accelerated drivers for OpenGL for the
major cards (Matrox,Nvidia,Radeon). Imagine the performance
of games under QT/Emb.
Lastly, I noticed that QT/Embedded is GPL'ed, but commercial
re-distribution necissitates a per platform fee. Would this
keep RedHat/Mandrake/Debinan/Suse etc from making an X 'free'
distro of linux. What if the distro was open?
Regards,
Jim Burnes
jburnes@vonu.net
Message 2 in thread
On Sunday 04 February 2001 01:26 pm, jburnes@geek.net wrote:
> (3) Since most QT and KDE apps are an easy recompile away from
> working on QT/Embedded, why are we still using X?
Because X11 works! Framebuffers are still slow on some systems. At work I am
running Solaris with only a framebuffer video. Even though the machine is
twice as fast as what I have at home, if that's what framebuffers are, I
don't want them.
Granted, there is some accelerated code for framebuffers, but they don't work
on all cards and even fewer kernels. Not everyone has the video card of the
week and the latest Linux snapshot. I, for one, don't.
> The result of all this would be an excellent 2D/3D accelerated
> environment for Linux that would be a natural platform for
> game development. At that point we would bid X Window a fond
> adieu. Thoughts on the matter? (let the fur and flames fly)
I found at leat a 100% speed improvement by simply rebuilding XFree86-4.0.2
with -O2 -mpentium. I also did the same for Qt and KDE, and I was blown away.
If you're using prebuilt binaries from a distro, they're most likely going to
be for i386 with not much optimization.
--
[ signature omitted ]
Message 3 in thread
On Sun, 4 Feb 2001, David Johnson wrote:
> On Sunday 04 February 2001 01:26 pm, jburnes@geek.net wrote:
>
> > (3) Since most QT and KDE apps are an easy recompile away from
> > working on QT/Embedded, why are we still using X?
>
> Because X11 works! Framebuffers are still slow on some systems. At work I am
> running Solaris with only a framebuffer video. Even though the machine is
> twice as fast as what I have at home, if that's what framebuffers are, I
> don't want them.
Yes, of course X11 works. But then so does my old Chevy Malibu and I
wouldn't want to drag race with it. Gaming effectively requires a
hot rod rendering system. I know this can be done (and has been done)
under X, but it seems like like a massively inefficient process.
This would also allow desktop Linux to run efficiently with less
memory.
>
> Granted, there is some accelerated code for framebuffers, but they don't work
> on all cards and even fewer kernels. Not everyone has the video card of the
> week and the latest Linux snapshot. I, for one, don't.
This will stabilize in time. I guess I should have clarified. I didn't
mean we should all switch over now, just that we might move toward that
as a goal. Certainly if embedded devices push the Linux market, the
desktop market might capitalize on it.
>
> > The result of all this would be an excellent 2D/3D accelerated
> > environment for Linux that would be a natural platform for
> > game development. At that point we would bid X Window a fond
> > adieu. Thoughts on the matter? (let the fur and flames fly)
>
> I found at leat a 100% speed improvement by simply rebuilding XFree86-4.0.2
> with -O2 -mpentium. I also did the same for Qt and KDE, and I was blown away.
> If you're using prebuilt binaries from a distro, they're most likely going to
> be for i386 with not much optimization.
>
You can certainly get speed improvements by pushing the compiler
optimzation a bit. Twice as fast is nice. I believe skipping X
entirely could lead to vast speed and memory optimizations.
Using less memory avoids swapping issues. Measure your system
performance when you start to thrash next time.
Lets face it, the future of the Linux desktop is definitely not
locked into the X-Window environment. With desktop systems
like KDE/QT and Gnome available sans X, why not take the last
leap. The only thing you have to loose is memory and CPU
bloat. (and your old, outdate X apps)
(that should stir the hornet's nest)
jim burnes
Message 4 in thread
On Sunday 04 February 2001 03:50 pm, jburnes@geek.net wrote:
> > Because X11 works! Framebuffers are still slow on some systems. At work I
> > am running Solaris with only a framebuffer video. Even though the machine
> > is twice as fast as what I have at home, if that's what framebuffers are,
> > I don't want them.
>
> Yes, of course X11 works. But then so does my old Chevy Malibu and I
> wouldn't want to drag race with it. Gaming effectively requires a
> hot rod rendering system. I know this can be done (and has been done)
> under X, but it seems like like a massively inefficient process.
I did slightly mispeak myself. A framebuffer, by *traditional* definition,
has no acceleration. The program/os writes directly to video memory. No
optimized hardware blitting, no 3d acceleration, nada. On the other hand, OS
level support for direct video access allows direct rendering, which can
vastly improve performance if there is a good driver written for the video
card.
When you say "framebuffer", I think of Chevy Malibu. When you say "direct
rendering", I think Lamborghini. I don't want a Chevy Malibu and I can't
afford a Lamborghini Since I don't need the video horsepower of a Lamborghini
to do development, check my mail, browse the web, etc. I am content with the
Plymouth Prowler that is X11.
> This would also allow desktop Linux to run efficiently with less
> memory.
But what you give up for that memory (which isn't all too much for X11) far
outweighs what you gain. I don't want a system optimized for gaming. I want a
general purpose computer. Qt/KDE shouldn't be just a game launching system.
Let the games use the direct rendering and keep the rest of the system just
as it is.
> > I found at leat a 100% speed improvement by simply rebuilding
> > XFree86-4.0.2 with -O2 -mpentium. I also did the same for Qt and KDE, and
> > I was blown away. If you're using prebuilt binaries from a distro,
> > they're most likely going to be for i386 with not much optimization.
>
> You can certainly get speed improvements by pushing the compiler
> optimzation a bit. Twice as fast is nice. I believe skipping X
> entirely could lead to vast speed and memory optimizations.
> Using less memory avoids swapping issues. Measure your system
> performance when you start to thrash next time.
I can't measure my thrashing because I don't thrash. Period. I haven't
thrashed on X11 since the days when I had 12Meg memory and every other
application was statically linked. But you're paying too much attention to
the memory needs of X11. It's not all that much. The common myth about it is
just plain wrong.
> Lets face it, the future of the Linux desktop is definitely not
> locked into the X-Window environment. With desktop systems
> like KDE/QT and Gnome available sans X, why not take the last
> leap. The only thing you have to loose is memory and CPU
> bloat. (and your old, outdate X apps)
You gain a little bit of memory and even less CPU time, but lose all the
remote capabilities, backwards hardware compatibility, backwards software
compatibility, cross-platform standards, and a whole lot more.
The last thing I want is to have to chase after the lastest video card just
so I can use KDE to check my email. I dumped Microsoft because they kept
treating me and my system as obsolete. I don't want the Unix world to end up
with the same arrogant disregard for the user base.
--
[ signature omitted ]
Message 5 in thread
On Sunday 04 February 2001 22:26, jburnes@geek.net wrote:
> (2) Our old friend, the X window system is getting a bit long in the
> tooth. The amount of extra baggage in X versus the frequency of use
> of those features (network transparency mostly) doesn't seem to
> justify the performance and memory hits we take everytime we render.
> There is nothing in X that I wouldn't be willing to do under VNC
> when I actually need that functionality.
That may be true for you but I can tell you that I'm very happy that I can
just telnet/rlogin to a machine, export the display (in that case, to an
Exceed windows client) and start apps on it. I'm doing this at work every
day, and if I had to set up VNC just for this, I'd be quite in trouble.
Right now I think many more people need the network transparency than faster
rendering. Given the current performances on even the cheapest PC you can get
on the market today, things like X or Emacs are plain regular-sized programs.
--
[ signature omitted ]
Message 6 in thread
On Monday 05 February 2001 07:26, jburnes@geek.net wrote:
> QT Wizards:
>
> This has probably been discussed at some length before I arrived
> on the list, but I had this vision....
> <snip>
> What would it look like? An RPM for KPE (K Pocket Edition),
> QT/Emb and hardware accelerated drivers for OpenGL for the
> major cards (Matrox,Nvidia,Radeon). Imagine the performance
> of games under QT/Emb.
>
Nice ideas but you loose all your GNOME and X apps. I use GIMP occassionally
and I wouldn't want to switch between X and Qt/Emb just to run the odd
X/GNOME program, may as well have everything under the one roof. Although 99%
of the time at work I'm using exclusively KDE apps so it wouldn't be so bad.
If you want to make things faster under X you could use the DRI to access the
screen more directly and accelerate your applications as Raster has
demonstrated with his canvas widget. You still have X and you have direct
rendering. Qt for X11 could even do this one day and have all the drawing
sent directly to the screen bypassing the XServer when the server == client.
Because the windowing system is abstracted away from the application by Qt,
it makes it possible for Qt to access the screen however it sees fit under X
so this could be done without needing to rework the applications, however it
would only speed up Qt and KDE apps, you may see this as either a good or a
bad thing.
An alternative way around the problem of loosing application support to make
your idea a reality would be to create a version of XLib which drew directly
to Qt/Emb instead of pumping out X protocol messages. Anyone feel like doing
that? This could make all applications run under it faster, not just Qt/KDE
ones, however they would be advantaged because they don't need to traverse
the XLib compatibility layer.
Both solutions require a relatively large amount of work
Regards
John
