XFree86 and KDE

Monday, 24 March 2003  |  Datschge

The XFree86 project, one of the major window systems hosting the KDE/Qt platform, released version 4.3.0 almost a month ago. This version incorporates many frequently requested features such as fully graphical mouse cursors with support for shadows and animation (3d.jpg, gold.jpg, tux.jpg), and on-the-fly screen resolution changes (dialog.png, kcontrolmodule.png, notification.png, popup.png). In other news, amidst some criticism regarding XFree86's current development model, the project has gained a much needed public bug tracking system as well as a new forum inviting public comment on the direction of the project.

The latter forum is already very active, and arguably a success, spawning an hourly updated XFree86 CVS changelog. Unfortunately, in a political shuffle, much loved X developer Keith Packard involved with FontConfig, Xft and the X RENDER extension found himself ousted from the XFree86 Core Team.

Update: 03/24 18:50 by N: A group of KDE and GNOME developers have released an open statement on the matter. The statement doesn't say much that hasn't already been said, though it lays out some key issues in point form.

Update: 03/25 00:36 by N: X.Org chairperson Steve Swales speaks up on behalf of the X.Org members.

Comments:

XFree86 new modular multilingual support and KDE - Guss - 2003-03-24

The new version supports a (non-backward compatible) new setup for multi-lingual keyboards, which doesn't work at all with the current kikbd and kcm module, both need to be changed to support the new API. currently I don't mind that much because I use Mandrake which changed their keyboarddrake configuration utility to support the new scheme.

Re: XFree86 new modular multilingual support and KDE - Sad Eagle - 2003-03-24

Do you have any link with info about the changes?

Re: XFree86 new modular multilingual support and KDE - Guss - 2003-03-24

look here: http://www.xfree86.org/4.3.0/XKB-Config2.html#4

Demanded changes - rjw - 2003-03-24

For people who want to know what is being requested of XFree86: Politically: * Actual admission that the XFree86 project is nowhere near as open as comparable projects - so far they are still maintaining their innocence * Work to change this - effectively this means being less mean about giving out CVS write access given the current record of core team innefficiency, and actually engaging with the main users of their work. * Stop believing that a few core developers are a better testing framework than their userbase. This is the bottleneck with driver updates. * Sadly it seems unlikely that the core team will forgive Packard anytime soon. This is not brilliant, as he has been one of the most visibly productive members of the XFree team. Technically: * New build system - imake is awful. Autoconf/ automake are the obvious choice. * Make disconnected trees easier - ie independently released drivers and extensions, which can be folded in later. * Listen to what desktop projects, the main users of the software, want: * Proper rendering model - ie RENDER like functionality that is implementable on modern hardware, and is properly accelerated. Some suggestion that this can be done via OpenGL - skeptics remain... * Make expose events actually work properly - ie no crappy redraw updates when windows are dragged around. This may be better solved by saving all mapped window contents. * Same with resize events - opaque resizing is excremental on X right now due to syncronisation issues. * Proper alpha channel model between toplevel windows- the shape extension is sick, and transparent terminal/menu hacks are outdated. * Good infrastructure for layering XFree on other window systems, ie Win32,GDI,DirectFB, X itself etc. So reimplementation is not a chore. Make it easy to get extensions like XVideo and glx working on top of other window systems. Also would ease transition to a theoretical X12, which would get rid of core cruft and change the protocol to be more suited to modern networks. Ie bigger packets, accept higher latency more gracefully. This all may be acheivable within the X11 framework. What sane people are NOT asking for: * Getting rid of the wire protocol: this request implies a severe misunderstanding of modern graphics hardware and 2d performance issues. * Moving network transparency to a screen scrape VNC model - this would be a massive step backwards. * Changing the driver model for GGI or FBDEV - efficient acceleration would not be easy.

Re: Demanded changes - theorz - 2003-03-24

I just have to say that I totaly egree with that list. At one time I wanted to help with xfree, but I could not find any way to ease into it. Maybe I will try again if they clean up the pollitical situation. Also using a modern rendering model that allows desktop opengl acelleration, and is not constantly forcing the windows to redraw would be a huge gain. Heck just saving all mapped window contents would be huge. I also agree with the not list. I find it funny how all the x (as a protocal) bashers completely miss the point when demanding x reforms.

Re: Demanded changes - not me - 2003-03-24

>* Proper rendering model - ie RENDER like functionality that is implementable > on modern hardware, and is properly accelerated. Some suggestion that this > can be done via OpenGL - skeptics remain... What's wrong with RENDER? It's implementable on modern hardware, and it can be properly accelerated. What possible benefit would OpenGL have over RENDER?

Re: Demanded changes - FooBar - 2003-03-24

RENDER is an X extension. OpenGL is a language for your graphics card to do hardware accelerated 3D drawing.

Re: Demanded changes - not me - 2003-03-25

That's correct. It also doesn't answer my question.

Re: Demanded changes - FooBar - 2003-03-25

I don't even get your question. OpenGL is for video cards. RENDER can be implemented on top of OpenGL. RENDER is not a replacement for OpenGL, while your question implies it is.

Re: Demanded changes - not me - 2003-03-27

RENDER is not a replacement for OpenGL in general, but it can replace the 2D portions of OpenGL for general windowing system use. The original post implied that X needed a new rendering model besides RENDER. I was asking why RENDER was not good enough. When I asked what benefit OpenGL had over RENDER, I was asking "what benefit would using OpenGL as a new 2D rendering model for X have over simply continuing to use RENDER?" If the original post was only talking about implementing RENDER on top of OpenGL, then I misread it. But I think the post was talking about replacing RENDER with something else, possibly OpenGL.

Re: Demanded changes - Myself - 2003-03-25

Accelerated for those who have acceleration support. Some of us (especially laptop users) are so unlucky that we're using savage or other S3 video cards. Not everyone can afford to buy a laptop with Nvidia G4 :-(

Re: Demanded changes - rjw - 2003-03-24

There have been issues with accelerating RENDER. Hopefully these issues can be addressed by eveolution of the spec. Currently *2 years* after RENDER was released, the mga driver has absolutely minimal acceleration and thats it for free drivers. XIG apparently has some acceleration too, after a fair amount of hair pulling. The problem was - the specifier, KeithP, didn't know as much about the hardware as the driver authors and hardware vendors, and they just didn't seem to care enough to have any real input into the process. Hopefull all this can be solved.... The OpenGL issue: there has been suggestion that the RENDER extension could be implemented over the top of OpenGL operations, with the X Server calling the OpenGL implementation for all 2D operations. So the X Server would become a user of the OpenGL implementation and most of XAA would go out the window. AFAIK, this would require the OpenGL driver to understand nested contexts - eg creating a context on a window which is then composited by the root context onto anything else... this whole method begs the question - why not just use the OpenGL API to draw everything (and just have a legacy X11 proxy)? The other idea was just to use the same facilities on cards as are used to implement OpenGL, and not reuse the drivers.

Re: Demanded changes - idspispopd - 2003-03-25

I really like that idea. As for just using opengl, I think that is too simple. The x server should be handling fonts, understanding nested contexts, and so on. I see it as a good split. opengl for getting the hardware to do its work. And having an x server on top of it that does the windowing specific work.

Re: Demanded changes - rjw - 2003-03-26

Well, duh. Of course I didn't mean *everything*, there needs to be a window system. Fonts is probably going client side from what I can see. Nested contexts is definitely an OpenGL issue.

Re: Demanded changes - Rayiner Hashem - 2003-03-25

The problem with RENDER is two fold: 1) Graphics cards don't support it yet. There is no point in defining another API if an existing, well support, and well established standard does the job. 2) RENDER (actually, Xr/Xc) is a 2D API. Not only does this restrict integration with more advanced OpenGL features (beyond the standard Postscript/PDF imaging model), it keeps the imaging model from taking advantage of the ever improving OpenGL API, and it makes life more difficult for driver implementors, who have to coordinate simultanious 2D and 3D rendering. To look at the big picture, both Xr/Xc and OpenGL are vector graphics APIs. There is no point in having two of them if you can have one and use a subset of it for 2D graphics. Now, from what I've seen, OpenGL seems to be suitable enough for advanced 2D graphics. SVGL (http://www.lri.fr/~conversy/svgl/), for example, has already implemented an SVG viewer using OpenGL, and has seen incredible (up to 100x) performance improvements. EVAS already has a very good demo using OpenGL, and OpenGL rendering looks just as good as their software rendering. Xr/Xc tries to implement a pixel-exact rendering model, which is of dubious use. For things where pixel-level accuracy matters (fonts), one can always use textured 2D triangle bitmaps, which is precisely what Quartz Extreme in OS X does.

Re: Demanded changes - Rayiner Hashem - 2003-03-25

More Info: The Amaya people also seem to be working with SVG and OpenGL: http://www.w3.org/Amaya/User/gldev.html Scroll down to the bottom of the page for some notes they made about using OpenGL to implement SVG.

Re: Demanded changes - Derek Kite - 2003-03-24

Another political / technical challenge is how to get the X consortium to accept changes. There are some issues with X itself that need fixing, and some feel there hasn't been effective representation to bring necessary changes. This whole thing will probably improve the situation for everyone. Every project goes through defections and controversy. Usually the issues are fixed as much as possible, and hopefully with time everyone simmers down. Even a fork may be necessary to permit an experimental approach on one hand, and a stable tree on the other. I think every project needs an Alex Viro to keep itself on track. Derek

Re: Demanded changes - Navindra Umanee - 2003-03-24

So what would be KDE's equivalent of Al Viro? Neil Stevens? *duck*

Qt/KDE on framebuffer - cies - 2003-03-24

before i start: 1. I don't mind using X. 2. I wouldn't mind -- corr. -- would love to see an alternative to X (and make used of it with KDE) 3. I am running the latest X server and liking it... ...i thank the X team for so much end-user-impotant-changes! See here a link to some info on gtk without X: http://mail.gnome.org/archives/gtk-list/2002-February/msg00022.html Would it be possible to do Qt/KDE without X? This link (from 2000) sais some on it: http://listserv.externet.hu/lists/linux/0003/msg00085.html Anybody got me some update info on this? (links, screenshots, etc.) Have a nice day... Cies.

Re: Qt/KDE on framebuffer - Chris Howells - 2003-03-24

> Would it be possible to do Qt/KDE without X? Sure, just re-write the bits of KDE that require X (there's not a huge amount of it). Supposedly some parts of KDE are already able to build without X.

Re: Qt/KDE on framebuffer - kurre - 2003-03-24

How about XDirectFB (http://www.directfb.org/xdirectfb.xml)? Has anyone tried it? Does it work with KDE?

Re: Qt/KDE on framebuffer - Richard Plante - 2003-03-24

This news item has made me wonder if I shouldn't look into alternatives like XDirectFB.

Re: Qt/KDE on framebuffer - Brendan Orr - 2003-03-24

You need X to run XDirectFB ====================== from the README: .... Short installation instructions: - Check out module "xc" from XFree CVS (www.xfree.org) - Apply patch "xc-directfb.diff" with "-p0" within "xc/" - Copy directory "programs/Xserver/hw/directfb" into "xc/programs/Xserver/hw/" - Copy files in "config/cf/" into "xc/config/cf/" - Adjust "xc/config/cf/host.def" - Run "make World", lean back, run "make" for safetiness, run "make install". ======================= I haven't tried it yet (checking out ATM) anybody use it though

Re: Qt/KDE on framebuffer - Brendan Orr - 2003-03-25

I just compiled it, it is nice and all, but slow (I.e. unaccelerated on my machine) Setting the default window opacity to 255 (100%) results in an ugly magenta background where transparency once was. Setting to 254 fixes the problem. Also, make sure to turn off the fade effect on menu transitions. Animate works, but it creeps out at a slow,steady rate instead of just popping out.. There are quite a few nice features to this (besides the ability to have true transparency with windows). For instance, all cursors get a soft drop shadow (I.e. MS windows cursor shadow). I haven't tested it with my cursor sets though.

XDirectFB - Guss - 2003-03-26

Your cursors probably got the shadow effect from using XFree86 CVS which has configurable animated cursors with support for shadows

Re: XDirectFB - Brendan Orr - 2003-03-26

the core set has shadows? I though it was just the new sets that were made from PNGs? (where the shadow as added using a graphics program)

Re: XDirectFB - Guss - 2003-03-26

The core set of 4.3 is a new core set, not the same as you've used before and it has shadows

Re: XDirectFB - Brendan Orr - 2003-03-28

Hmm, it must've not been in the official release because I reverted to the pre-compiled binaries and there is no shadow (with the exception for the CursorShadow option which I have used since the beginning of 4.2). oh well :)

Re: Qt/KDE on framebuffer - Justin - 2003-03-26

Yes it works with KDE. Setting it up is a pain though. First, It is really just a patch to XFree86, so you have to download the huge sources (100MB+ or so) and compile everything. Second, you have to somehow get it to co-exist with your existing XFree86 installation (not easy, but not XDirectFB's fault). I used it around summer of 2002, and it worked pretty well. Unfortunately, it didn't support many of the X extensions, so some apps refused to run (notably VMware and anything 3D). On the positive side, setup is a breeze. It uses the keyboard/mouse/video drivers of the kernel, so things just work. The transparency tricks are a bit useless, but they prove a point. XDirectFB also claims to be able to run normal DirectFB software (like that GIMP port), managed with your X11 window manager. I never tried this, I was just happy to be using a nicer X server for once. I went back to normal XFree86 a few months later. IMO, XDirectFB is the future of the Linux desktop, but it is not ready yet.

Re: Qt/KDE on framebuffer - KDE User - 2003-03-24

There is Qt/Embedeed and kde-nox already.

So: XdirectFB is an option but no alternative yet! - cies - 2003-03-26

So: XdirectFB is an option but no alternative yet! (Had to conclude some from the intersting Re's on my post...) I think linus desktopping will stay with X for a looooong time, cauz: - desktop pc's are getting faster and faster - x works and does a lot - lot's of stuff dep.'s on/uses x... - when the FB stuff matures we want networkt transperancy in it ;) I think opensource movement must be happy to have a good standard! But the freedom of choosing something less bloaded will only enrich... Have a nice day, Cies.

KDE support - AC - 2003-03-24

So what is the status for KDE support of these features like the fully graphical mouse cursors and resolution changes? Is that stuff coming for KDE 3.2? Also, with Keith kicked off the XFree team, might they decide to throw away his work on the RENDER and RANDR extensions?

Re: KDE support - Somebody - 2003-03-24

Are they stupid/fanatic enough to do that? If so, there should be a "cleanup" in the XFree BOD.

QT re-drawing issues are slow not X ??? - ac - 2003-03-24

Not sure if this is OT or not but everytime the discussion comes up on ./ about throwing out X, someone suggests that X itself is not slow, but that the modern toolkits (gtk and qt) are not written to take advantage of X (ie they redraw incorrectly etc). I actually have no clue about this but was wondering if anyone here could explain it. Obviously KDE does a lot more that twm, but is this eye candy that is slowing down X or toolkit problems? Does QT have inherent X problems (I wouldn't think this to be the case)? (This is NOT a troll, I'm really would like to know)

Re: QT re-drawing issues are slow not X ??? - David Johnson - 2003-03-24

I don't know anything about redrawing "incorrectly", but I'll try to take a stab at it... The way Qt draws themes involves drawing primitives with X11 (or GDI under win32). For a complex control such as a button with a bevel, gradient background, pixmap icon, and AA label, a lot of primitives get called to draw the button. This happens each time the button is redrawn. To make things go faster, the obvious solution is to cache a pixmap of the finished widget the first time and bitblt on any redraws. But who does this? X11, Qt or the theme? Either one of the three are viable options. The best choice though would be X11, as this sort of stuff belongs on the X server. There is some areas where Qt should cache or double buffer, and it does. But Qt is merely a toolkit, not the base GUI system. It shouldn't have to worry about whether the server is local or remote, whether some window is going to intercept any drawing events, or whether to use video or local memory to cache in. Just my thoughts...

Re: QT re-drawing issues are slow not X ??? - Marvin - 2003-03-24

Don't know anything about what Qt/GTK do right or wrong, but here's another possible culprit: the scheduler in the kernel (i.e. Linux in most cases): X11 is a user-space process. So, whenever a GUI application reacts to a user event (eg. a mouse-click), the CPU has to switch from the X11 process to the application process and back. Many think that the time it takes to do these context switches is the problem. However (particularly since Linux is pretty fast at context-switching) I can't imagine that this takes more than a few milliseconds (probably even less than one) - so that would hardly be noticeable. But if the kernel doesn't switch directly from X11 to the GUI application (or back) but instead gives a timeslice to yet another process in between, the reaction to the user event will lag. The brute force way of dealing with X11 slowness proposed by many is to put the graphics driver in the kernel. But that wouldn't even deal with the problem above: the gfx driver would probably be implemented as a kernel thread, and if that isn't scheduled correctly, you still get a slow GUI. The only advantage would be that you could give special treatment to that thread in the kernel since the kernel knows that this is the graphics driver. But that special treatment could also be done for a user- space process, so in the end putting the gfx driver in the kernel doesn't buy you much - but gives a lot of headaches instead: Gfx drivers are pretty complex and hence often instable - at least when compared with the stability of Linux. Anyway, I've heard that the kernel developers are on it for 2.6. As usual with the Linux developers, they don't want to hack up a special treatment for X, but go for a generic solution, because apparently there are other situations where the same scheduling problem arises.

Re: QT re-drawing issues are slow not X ??? - Ned Flanders - 2003-03-26

If the problem was coming from the scheduler giving too much cpu time to other processes instead of X when switching context, then it would be relatively easy to correct it by giving an higher priority to X. However, this doesn't increase X performance on a mostly idle system. As X is also slow on these systems, the problem is probably elsewhere in the X architecture.

Re: QT re-drawing issues are slow not X ??? - AC - 2003-03-26

You are saying that X11 is slow all the time. I wonder how you come to this impression. Maybe you have a slow driver? With both the ATI r128 and the proprietary nvidia drivers I was never ever able to see a redraw or something else that would make X11 appear slow.

Re: QT re-drawing issues are slow not X ??? - Ned Flanders - 2003-03-28

I'm using the ati driver. I know that 3D support on the mach64 is experimental on Linux, but won't use it as a point of comparison. However, I think 2D graphics performance can be compared with Windows, and window moving/resizing is really faster on Win2K, even if my CPU is idle. The difference may not be visible on new hardware, but isn't Linux useful on older computers?

Re: QT re-drawing issues are slow not X ??? - Tim Jansen - 2003-03-24

I can't comment on Qt, but the right way to do X11 calls is to minimize interactions between the client and the server, especially during a redraw. You should minimize queries on the client-side, and especially should not put a query between your drawing commands. The general problem with xlib is that it is not transparent which function will cause a interaction with the server, and under which circumstances. xlib will cache information to a certain extend, but it is often hard for the application/toolkit developer to find out when it caches. A few people have worked on a more direct, non-caching API for the X11 protocol called XCB (http://xcb.wiki.cs.pdx.edu/cgi-bin/twiki/view/XCB/XcbOverview) which would make this more transparent for the toolkit developer. I don't know it's current state, last time I checked it lacked support for most extensions, and AFAIK not a single toolkit has been ported to it.

So how do I get the snazzy cursors and kcmrandr ? - TimLinux - 2003-03-24

Ok, so I have xfree86.4.3 and kde 3.1.1 built using konstruct. How do I actually get the tools and cursors shown in the screenies built on my system? Thanks Tim

Re: So how do I get the snazzy cursors and kcmrandr ? - Brendan Orr - 2003-03-25

Its easy enough. 1a)go to www.kdelook.org, www.themedepot.org or some other theme/resource site and get a new icon set. 1b)Use one of the default icon themes that are shipped with 4.3.0(or 4.2.99). They are whiteglass, redglass, handheld, and core(the old B&W default). 1c)Make your own :) If installing for a single user(or a particular user): 2)make the directory "~/.icons" 3)copy the "cursors" directory and "index.theme" from the archive to ~/.icons 4)restart X If installing system-wide: 2)extract the archive contents to its own directory in /usr/X11R6/lib/X11/icons (E.g. you would have a .../X11/icons/reddot directory with its own cursors directory and index.theme 3)edit the index.theme in the default directory to say: [Icon Theme] Inherits=theme obviously replacing theme with the themes name Alternatively, if you just want to test a set out you can set the variable "XCURSOR_THEME" to a cursors name and "XCURSOR_SIZE" to set the size of the cursor to any size (yes, you can have a 128x128 cursor if you wanted to) To make your own or for more info check out uga's Red Dot theme. It includes a Cursor Making HOWTO along with a probably more clearer documentation on how to install :) http://www.kdelook.org/content/show.php?content=4805

Re: So how do I get the snazzy cursors and kcmrandr ? - Hamish Rodda - 2003-03-26

kcmrandr is in the cvs module kdenonbeta. An example of how to check out just kcmrandr is here: http://svg.kde.org/status.html (replace ksvg with kcmrandr) Then, follow the readme. I'm sorry it can't be any easier, because you need to apply patches to Qt, kdelibs and kdebase to make it work properly...

Re: So how do I get the snazzy cursors and kcmrandr ? - Navindra Umanee - 2003-03-26

Hey nice job, btw! I think we need to fit it in a better section than "Look & Feel" in KControl. Also, I guess we don't need to repeat the screen dimensions in mm for every resolution. :-)

Re: So how do I get the snazzy cursors and kcmrandr ? - Anonymous - 2003-03-26

"Look & Feel"? Maybe you should update to KDE 3.1? ;-)

Re: So how do I get the snazzy cursors and kcmrandr ? - Myself - 2003-03-26

He may have it, since the directory is still called LookNFeel even in CVSHead. (I'm talking about the real directory name, not the name that shows in the menu).

Re: So how do I get the snazzy cursors and kcmrandr ? - Navindra Umanee - 2003-03-26

Actually, as Hamish noted I was looking at some old screenshots. But you're right, Look & Feel is gone from KControl.

Re: So how do I get the snazzy cursors and kcmrandr ? - Hamish Rodda - 2003-03-26

Thanks :) Those screenies are really old though, both issues are fixed. Now it only needs a cosmetic lift (maybe a picture of an LCD screen with the changes being displayed).

Time to open the eyes - Scythe - 2003-03-26

It seems like the people at the XFree86 project had ( or have? ) their eyes closed for a long time. When you open your eyes and look around you'll see two big players on the desktopmarket. Apple has done a great job with their latest OpenGL accelerated userinterface. Really slick, and one of the major reasons OSX became intresting for the desktop. Microsoft is planning Direct3D acceleration for their graphical shell, and will surely not take long to be implemented. However XP has nice graphics, they too realize that it is time to go further. Especially now a 3D accelerated card is all but rare in today's common homecomputer or workstation. In the mean while, the GNU/Linux OS becomes more and more popular. While applications shipped with current distributions get better and more accessible to common homeusers, the graphical environment is still behind the commercial implementations. Things like antialiased fonts and the new features of XFree 4.3 are surely a step forwards, but it can be so much more. I can not imagine there aren't people who share my desire of a fully OpenGL ( <- most obvious choice imho) accelerated desktop showing of nice effects that make OSX users cry, unmatched performance, and a better chance of graphiccards companies writing drivers for it. I realize that not everyone has a state-of-the-art graphicscard in their system, but that problem could be solved by just letting the OpenGL renderer run in software mode. Backwardscompatibility should -however i am not familiar with the current XFree codebase - not be hard to achieve, writing simple wrappers or emulation layers. So the question may be: "Is it wise to stop innovation in fear of releasing the past?" I think it's time to look closer at people who have already achieved what the goal should be for the current graphical environment(s) on the GNU/Linux platform. Regards, Scythe.

Re: Time to open the eyes - Datschge - 2003-03-26

The problem is not that people have no "good ideas" but that only very few are actually trying to realize those "good ideas" at all as well as that there's too little support for those few who do try.

Re: Time to open the eyes - Rayiner Hashem - 2003-03-26

Unfortunately, Quartz isn't actually OpenGL accelerated. OpenGL is only used to accelerate compositing of windows. Everything *inside* the windows is drawn in software.

Re: Time to open the eyes - FooBar - 2003-03-27

Which is a good thing to do. OpenGL sucks at 2D operations! Drawing 2D in OpenGL may actually slow things down.

Re: Time to open the eyes - FooBar - 2003-03-27

"When you open your eyes and look around you'll see two big players on the desktopmarket. Apple has done a great job with their latest OpenGL accelerated userinterface." Oh no not this overrated stuff again... Quartz is *slow*. It *feels* fast, but if you compare framerates then Quartz is *slower* than XFree86. Just by using OpenGL doesn't automatically give you drop shadows or uber-l33t-performance or whatever. OpenGL is meant for 3D. 2D operations in OpenGL is *slow*. Blitting in OpenGL is *very* slow. Imagine what happens when a high-framerate 2D app tries to blit everything through OpenGL. It would kill performance rather than improving it. The usage of OpenGL only accelerates drawing in certain cases, but also *slows down* things in other cases. "Really slick, and one of the major reasons OSX became intresting for the desktop." While still being stuck at 2% market share... Windows XP users don't seem to care about "3D-accelerated GUIs". "I realize that not everyone has a state-of-the-art graphicscard in their system, but that problem could be solved by just letting the OpenGL renderer run in software mode" !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Try running Tux Racer in non-accelerated Mesa (software OpenGL rendering). Be happy if you can manage to exit Tux Racer in 10 minutes using the menu. Do you want your windows to draw at 0.5 fps too? "So the question may be: "Is it wise to stop innovation in fear of releasing the past?"" It is not wise to implement hyped designs just because they're hyped. OpenGL is not the ultimate solution to everything!

Re: Time to open the eyes - Rayiner Hashem - 2003-03-27

Quartz is *slow*. >>>>>>> Yes, it is. It's also all done in software. In OS X, Quartz Extreme (the OpenGL acceleration) only comes into play when all the drawing is done and it's time to composit all those transparent, drop-shadows windows together. All Quartz2D calls are still rendered via the CPU. The big reason Quartz Extreme was such a performance boost for the OS X folks is because, before QE, the CPU was doing all the drawing *and* all the compositing. Blitting in OpenGL is *very* slow. Imagine what happens when a high-framerate 2D app tries to blit everything through OpenGL. It would kill performance rather than improving it. >>>>>>>> Actually, the speed of 2D operations is dependent on the implementation. On workstation-level implementations, 2D operations are very fast. On many consumer level implementations, the 2D subset (glCopyPixels, etc) is (was) rather slow. I haven't benchmarked 2D operations on modern NVIDIA (or ATI) hardware, but since's NVIDIA's OpenGL implementation is good enough to be in SGI workstations (all the Intel VPro chips are modified Quadros) I'd guess 2D operations would be quite fast. Of course, all of this is rather irrelevent. The modern way to do 2D blits is with textured quads. Both the ATI and NVIDIA implementations allow you to use arbitrary texture sizes, so no scaling is involved and the end result is exactly equivilent to blitting, and is *very* fast. It should be noted that modern consumer OpenGL implementations are very good. In the past, consumer-level cards struggled if more than one OpenGL window was in use at a time. On my GeForce4Go, however, 6 glxgears shows only a nominal drop in total framerate over the 1 window case, and with 3 windows there is actually an *increase* in total framerate. The usage of OpenGL only accelerates drawing in certain cases, but also *slows down* things in other cases. >>>>>>>>>> Depends on the implementation, but that shouldn't be the case for any modern implementation. From what I've read at the SVGL and AmayaGL sites, most of SVG can be accelerated by OpenGL, including gradients and filters. Windows XP users don't seem to care about "3D-accelerated GUIs". >>>>>>>>>> Hello? That's one of the huge new parts of Windows Longhorn. It's supposed to have a fully Direct3D accelerated GUI. Blitting in OpenGL is *very* slow. Imagine what happens when a high-framerate 2D app tries to blit everything through OpenGL. It would kill performance rather than improving it. Try running Tux Racer in non-accelerated Mesa (software OpenGL rendering). Be happy if you can manage to exit Tux Racer in 10 minutes using the menu. Do you want your windows to draw at 0.5 fps too? >>>>>>>> Now that's the kicker. Software rendered GL is *very *slow. This is where the "leaving the past behind and daring to innovate" bit comes into play. You can have an optimized software-rendering fallback, as EVAS does, but it won't really run apps that take full advantage of the increased rendering power.

Re: Time to open the eyes - SadEagle - 2003-03-28

I've tried glDrawPixels a while ago on a TNT2 with NVidia drivers. It was horrid, taking near a second to blit something like a 640x480 rectangle. Even using XPutImage and synching the GL and 2D streams seemed faster, IIRC! Textured quads are an option, but they're also a /hack/. Unextended GL gives you only the power of 2 textures - other sizes are vendor extensions; and an implementation only has to support something that's 64x64, so the user has to do tile cache management. It's prolly a big win in many cases when the HW accel is there, but it's also quite possible that the decicated 2D accel may be more usable on some hardware. And I think yes, the real kicker is that you can't really find out what will be accelerated and what wouldn't be. That's because OpenGL is the wrong layer, really, IMHO. What we need is closer to the driver inside the GL implementation, which provides only the accelerated primitives, and the information on what it supports, etc. Most of the upper layers are useless, and provide rendering that's too complex for the 2D case. Do we need the T&L pipeline (which in S/W for older accelerators)? No. Support for controllable Z-buffer, etc.? Nope.

Re: Time to open the eyes - Alex - 2003-03-28

How long ago did you try doing that test? I've got a TNT2 as well and a while back I tried using the OpenGL video output from mplayer and it crawled. It was worse than the plain x11 driver, and many, many times worse than xv. A few days ago I tried the gl driver again and this time it worked fine. As far as I could tell, the performance was the same as what xv provided.

Re: Time to open the eyes - Sad Eagle - 2003-03-28

Gosh, that could have been 1.5 - 2 years ago, true.. At any rate, current versions of mplayer use textured quads, not glDrawPixels, and they have for at least 2 years if WebCVS isn't lying. The difference you saw could be an improvement in the driver of course -- video obviously uploads lots of data, so it has to load new textures a lot; perhaps NVidia optimized anonymous texture upload a bit. On the other hand, it could also be an improvement to the software YUV -> RGB conversion it needs. At any rate, I think it'd be hard for OpenGL to compete vs Xv here -- Xv is very much designed for good/fast video, and it can handle YUV natively.

Re: Time to open the eyes - FooBar - 2003-03-28

"Hello? That's one of the huge new parts of Windows Longhorn. It's supposed to have a fully Direct3D accelerated GUI." Microsoft != it's users. *Microsoft* cares. Most of it's *users* do not. Try convincing my grandmother to switch to Longhorn just because it has this "exciting new 3D GUI".

Re: Time to open the eyes - Idimmu - 2003-03-28

Users content to use legacy hardware should also be content to use legacy software, and stop ruining it for us that want something good! I have a h/w 3D card, and if that would make X really spiffy then I say, so be it!

Quartz Extreme framerates - mpaque - 2003-05-02

FooBar wrote: > Quartz is *slow*. It *feels* fast, but if you compare framerates then > Quartz is *slower* than XFree86. The Quartz display acceleration system normally limits framerates to the display refresh rate when an app issues multiple sequential flushes. Trying to go faster than that produces no visible effect, as the intermediate frames simply won't appear on screen, and is effectively a waste of bus bandwidth. Try flushing a window as fast as you can. The system will report a flush rate remarkably close to the refresh rate. An app will get the best results and highest overall performance in either Quartz or Quartz Extreme by doing needed computations and I/O, then drawing, then issuing a flush. This will interleave GPU and CPU operations.