Being a BeOS user (a purely desktop system) and because I code under Linux, I see XFree86 (v4.1 on my machine) as a user and as a developper. And this is where the problem lies. My Gnome or KDE desktops are slow in comparison with other operating systems, but XFree86, the ‘engine’ behind these desktops, proves me that it’s not. Let’s look at what I have in front of me: a dual Pentium III at 933Mhz with 512MB of memory, a Radeon 32 AIW, a modified Mandrake 8.0 powered by kernel 2.4.18.
Editor’s notice: Guillaume is not a native english speaker, so please excuse any grammar mistakes.
1. First approach of XFree86
My experience as a user is that this user interface is very bad speed-wise, sometime menus or buttons are slow to react, the refresh of the windows is a disaster (regardless if the apps are Qt or GTK+) as I can see too many ‘white areas’ because the toolkits do “refresh” parts of the windows too often. Should I reboot under BeOS and relax away from these problems? No, I will see what I can do with that with ‘C code’ as I am a software engineer, I have to evaluate XFree86 before formating my Linux partition. I did evaluated it, 15 months has passed and that was the time when I started BlueEyedOS. This disk was never formated. Linux was there to stay. Let’s see why.
2. From the coder point of view
Let’s start with the API and general concept, XFree86 is mainly a server (the X Server), it deals with gfx drivers and input drivers. When you want to use its functionality in your program, you use the Xlib library. That’s simple in theory. But in practice, it’s not as easy, as the API is not easy to memorize and the semantic is very abstract for people who only want to simple things, eg. to draw a red line on the screen.
2.1 Abstraction
All seems to be ‘perfect’ when using Xlib becasuse you don’t need to bother about the colorspace and conversion, all is handled automatically by the system. If the server is not on the machine which runs your program, you don’t have to worry about it, all the information are send through the network, it’s transparent.
2.2. Modularity
With XFree4, all is modular, the server loads and uses only the needed drivers. If you need new functions, you can create a new extension. All this sounds good, but the dream stops here.
2.3. Performance issues
– all the communication is socket based (even if your machine runs the client and the server)
– useless conversion. Colors are defined with 3 fields (red,green,blue), 16bits by component. If you need a ‘pure red’ color, you will have to write:
XColor color;
color.red=65535;
color.green=0;
color.blue=0;
It implies 2 conversions, 1 from the client, which converts 24bits data to 3*16bits data and send them to the server. The second conversion is done by the server, which convert them to my 32bits display…
– Lack of transparency support
You simply can’t use transparency without coding it yourself, the X Rendering Extension is supposed to solve this issue, but it’s still quite “unusable”.
3 Let’s use it as it should be for high performance
To test a small ‘proof of concept‘ I did months ago, you will need a 1024×768 32bits display running under XFree. You will see that you can smoothly move windows around your desktop, with a cpu consumtion very-very low and a fast responsivness. How did I do it? I minimized the impact of the flaws of the design, which means:
– to reduce the communication between the server and the client
– to use the memory of the gfx card memory
– to use a minimal set of X11 functions
– to redraw only what is needed
Here, we have to define 3 ‘spaces’:
– the framebuffer (FB) which is the part of the memory of the gfx card which is drawn on the screen
– the memory of the gfx card(GRAM), used to store bitmap
– the main memory (RAM) (in the client adress space)
XFree86 provides an ‘object’ called “Pixmap” which is a bitmap that can be stored in the RAM or in the GRAM, it provides a big acceleration when you need to draw bitmap but needs to be used carefully, because you don’t control the memory management in GRAM.
3.1 Let’s benchmark!
XFree86 provides a tool called ‘x11perf’, on my computer the XServer can:
– draw 18000 lines/s
– draw 30000 filled rectangle/s
– copy/blit 1250 (1500 using the SHM extension) 100×100 bitmaps/s from RAM to FB (or RAM to GRAM)
– copy/blit 24000 100×100 bitmaps/s from GRAM to FB (or GRAM to GRAM)
If we consider that something fast & smooth is about 25frame/s, we can only draw by frame, if we want to stay ‘fast’:
– 720 lines
– 1200 filled rectangles
– 50 (or 60) copys of 100×100 bitmaps
– 960 blit from GRAM to FB
Because a modern interface is not composed of filled rectangles, the only way to keep have something nice is to blit as much as possible. But it’s not so easy!
Let’s try another benchmark, the goal is to create a fade (from black to white) in 256 increments, the fade is done twice. It means that for 25fps, the test must end in less than 20s.
The first colums show the time it took when running 2 tests at the same timen, the second column show the result when only one test is executed.
The first test, it uses the the XFillRectangle function to create the fade. The second one, draw the filled rectangles point by point…
The third one, draw the filled rectangles line by line…
The fourth one, create the rectangles in RAM, tranfert to GRAM and blit from GRAM to FB.
The last one, create the rectangles in RAM, and blit from RAM to FB.
With 2 tests in parallel | 1 test for 512 operations
——— 320×256 —————
Filling the window with XFillRectangle
1 : 0 s 120 ms | 0 s 78 ms
2 : 0 s 79 ms |Filling the window with XDrawPoint
1 : 7 s 329 ms | 3 s 724 ms
2 : 7 s 120 ms |Filling the window with XDrawLine
1 : 6 s 761 ms | 3 s 245 ms
2 : 5 s 427 msFilling the window with XPutImage+XCopyArea
1 : 9 s 814 ms | 6 s 283 ms
2 : 10 s 104Filling the window with XPutImage
1 : 10 s 485 ms | 6 s 284 ms
2: 10 s 446 ms——– Same in 1047×768 ———
Filling the window with XFillRectangle
1 : 0 s 365 ms | 0 s 128 ms
2 : 0 s 270 msFilling the window with XDrawPoint
1 : 57 s 35 ms | 32 s 3 ms
2 : 51 s 62 msFilling the window with XDrawLine
1 : 7 s 270 ms | 5 s 307 ms
2 : 6 s 138 msFilling the window with XPutImage+XCopyArea
1 : 80 s 77 ms | 56 s 28 ms
2 : 93 s 469 msFilling the window with XPutImage
1 : 53 s 223 ms | 37 s 416 ms
2 : 52 s 684 ms
Conclusion, on 320×256, my computer competes with my Amiga 500 (14Mhz + 1MB of memory).
Now, with a fullscreen test, you will see that only XDrawLine is efficient, no surprise, it uses less bandwidth than the transfer from RAM to GRAM. Should we conclude that the XCopyArea + XPutXImage are not good performers? Surely not, because in 80% of the case, you work with the same bitmap (typically, the icon of your preferred app), then to draw it on the screen, a copy from GRAM to FB is enough (XCopyArea).
However, the figures in the first columns don’t make me very optimistic and really shows the limits of the Xserver in a multithreaded
environment. It needs improvements.
4. Interesting improvements
An interesting extension of XFree is the SHM one, it provides a new API (close to the XPutImage one) to transfer bitmap by using shared memory between the Xserver and the client. The gain is about 20% on ‘my’ typical use case, not bad! The ‘new’ extension called ‘XRender’ is an extension to XFree86 that lets applications perform complex blending and transparency operations. Functionality is interesting, but performance are not there, even a small semi transparent window (100×100) is slow. We need something faster and simpler.
It’s a bit of a parodox, I played with hardware accelerated OpenGL, it seems that my card can blit 32bits bitmap with transparency as fast than XFree blits non transparent bitmap… what’s more, an other lack I didn’t mentioned before, seems to be filled on the 3D part : synchronization with the refresh rate of my screen. Where is the magical function “WaitForVerticalBlank()”? It could increase the rendering quality and the feeling of nice scrolling, MacOSX use it, why not XFree?
I found many answers in the source code of my driver (and its DRI part), it looks like drivers could support acceleration for 32 bit data, but it’s not used or masked because the X server don’t use it, I’m interested to hear the reasons of this situation, IMHO the drivers MUST support transparency EVEN IF today no extension use it.
5. What can be done to improve it
A lot of thing can be improved, people always suggest the abandon of XFree, what I suggest is something more realistic (doable and efficient):
5.1. Simplify
The X11 functions are too much complicated, too much overhead and potential mistakes to be made. Developers need basic and efficient APIs. Some developers tried to solve this issue by creating a wrapper but it only adds limitations and decrease the execution efficiency. Modern hardware supports 32bits display, all we need is a new extension, which only works with 32bits local display allowing to
– create 32bits window window_id id=CreateWindow(int width,int height); and human readable functions like SetTitle(char*), SetSize(int with,int height), SetPosition(int x,int y), Show(), Hide()…
– create 32bits bitmaps(native ARGB format of the card) (always strored on shared memory) bitmap_id id=CreateBitmap(int width,int height);
– explicitly define functions like
bool StoreBitmapInGFXRAM(bitmap_id);
bool RemoveBitmapFromGFXRAM(bitmap_id);
void BlitToWindow(bitmap_id src, window_id dest, …)
void BlitToBitmap(bitmap_id src, bitmap_id dest, …)
void WaitForVerticalBlank()
5.2.Make it faster
This interesting extension should have a fast communication between the server and the client, by avoiding encoding/decoding and format conversion and using fast IPC like a shared memory. (the 3D part of XFree uses DRI which use this kind of shortcuts).
5.3.A typical use case, a window manager.
Let’s change a bit the subject and talk about the window managers (WM), most of us use a WM. A WM is a process (a X11 client as a standard graphical app) which deals with XFree86 for windows operations like moving windows, drawing the borders of the windows, manage workspaces etc. It’s the most used X11 application, and the one to blame for the slow refreshes we get on our desktops. Technicaly, when you move a window by draging its title bar, the WM will ask the Xserver to move the window, it will generate ‘redraw events’ (called ‘ExposeEvents’) to all the windows behind the moving one. Later all this windows will redraw themselves by using X11 functions (which implies to send message to the Xserver).
In practice: let’s start with an example: a screen with 10 windows.
1. I click on my preferred window and move it
2. the first ‘step’ of the move will:
– ask the Xserver to move the window
– 5 windows are partly covered, so 5 windows receive an ExposeEvent these 5 windows redraws the needed part. A ‘standard’ part of a nice UI need to send more than 100 drawing requests (line, rect, font…) to the Xserver. If my GnomeCalc is right, it’s about 500 requests at every ‘step’, if I want to be have the more smooth desktop on earth on my 100Hz screen, 500000 requests must be swallowed per second…. good luck, it’s not going to happen! Remember, it was ‘just’ to move a window and it already consume 100% of my CPU.
5.4. Make things faster, all the time…
If I look at my benchmarks and what was described as ‘bad’ on Xfree, a good solution could be to use the memory of my GFX card, by sacrifying 8MB, you can put a built-in window manager IN the X server (which plays with bitmap blitting functions to give you an impressive result).
5.6. Don’t re-invent the wheel
XFree already has a big potential, let’s improve it by creating the most efficient API, who cares about slowing a bit the Xlib functions if Xfree can provide something that outperform the old standard?
When working on the graphical rendering of B.E.OS, I never modify XFree86, but I use as much as possible of what is good on it, I hope that the result will seduce you and will push the development of a ‘better extension’.
6. It’s time to conclude
Yes, XFree86 is fast, just add the appropriate extension in order to use ‘shortcuts’ (as explained before) and you will have something performing fast, which can be used both with the standard X11 API and the proposed one.
About the Author:
Guillaume is a software engineer, who started to write his first line of code at 7, now he is 26… Amstrad, Amiga and a x86 PC under
BeOS are his preffered digital environements. After working at Philips on the MHP technology, he created his own company. Even with his spare
time drasticly decreased, he continues to find the time to work on exciting projects, like B.E.OS.
and it’s really impressive. If you can achieve that “responsiveness” using Xfree, I guess that B.E.OS have definitively a great potential – I know that responsiveness is more that the display capability but it’s a part of it.
XFree86 needs to be faster,easier,smaller and better looking.
what needs to happen is a Fork in development. 1 going purely desktop and 1 Keeping Client/Server socket crap.
I think it should be up to Gnome and KDE to make this fork happen. If they ever want to be recognized as a decent enviroment.
” – all the communication is socket based (even if your machine runs the client and the server)”
I thought that if it was local, X would use shared memory?
Bit nitpicking though
Guillaume touches upon the symptoms of my biggest problem with X: the drawing code being part of the server, and consequently its poor use of shared memory. The symptoms appear in the way redraw events are handled:
In practice: let’s start with an example: a screen with 10 windows.
1. I click on my preferred window and move it
2. the first ‘step’ of the move will:
– ask the Xserver to move the window
– 5 windows are partly covered, so 5 windows receive an ExposeEvent these 5 windows redraws the needed part. A ‘standard’ part of a nice UI need to send more than 100 drawing requests (line, rect, font…) to the Xserver. If my GnomeCalc is right, it’s about 500 requests at every ‘step’, if I want to be have the more smooth desktop on earth on my 100Hz screen, 500000 requests must be swallowed per second…. good luck, it’s not going to happen! Remember, it was ‘just’ to move a window and it already consume 100% of my CPU.
The server can ask the client at any time to redraw any portion of any of its windows. Not only does this make the clients unnecessarily complicated, but it leads to visible performace problems.
Quartz handles this by either: using a shared raster buffer which the clients can draw to directly, or by building a PDF document in memory that the server can re-render at any time without consulting the client. Because of this there is no display corruption when an application stops responding or is slow to respond.
X further suffers from having to multiplex what is sometimes very heavy socket traffic. In some cases this is enough to grind the X server to a halt as a particular client passes a barrage of drawing commands.
In a properly designed window server, IPC should only be used for synchronization and event processing, and all drawing should take place through the use of shared memory buffers. Clients should only have to redraw the entire buffer in the event that the window is resized.
Note that Win32 uses a similar architecture to X. Redraw lag is most visible in Windows XP when using shaped windows (as XP does per default with the Luna theme) See:
http://fails.org/xp
(taken on a 2GHz Pentium 4 system with the lastest stable Nvidia drivers, GeForce4 MX, and on a Pentium III system with a Rage 128)
People attribute this display corruption to “programming errors” in Putty and Internet Explorer. However, I attribute these problems to fundamental flaws in Windows itself. It shouldn’t be possible for such display corruption to occur during redraw events through “programming errors”. I think these screen shots make clear that having clients handle redraw events just isn’t a very good way of doing things.
Quartz has shown a better way of designing window servers, and after using it, any other window server seems outmoded and clunky.
” – all the communication is socket based (even if your machine runs the client and the server)”
I thought that if it was local, X would use shared memory?
Apparently you missed the whole second half of the article. He starts out by discussing the SHM extension:
An interesting extension of XFree is the SHM one, it provides a new API (close to the XPutImage one) to transfer bitmap by using shared memory between the Xserver and the client.
He’s talking about how X11 was originally intended to function with the first statement.
> However, I attribute these problems to fundamental flaws in Windows itself.
Bascule, you link these screenshots over and over. I told you in the past and I will tell it again: I am here with a much more slower PC than yours (dual Celeron 533, Voodoo5) and I don’t see any of your problems with XP. I think your problem is buggy drivers, or drivers not interacting well with your PC. I would try a different gfx card before I attribute these specific problems to WinXP rather than the person who wrote the drivers.
Good job! I have just a fight on my mailing list: “why linux isn’t good for a desktop” and this is one big reason – xfree it’s damn slow 🙂
You have got to be kidding. You.. using a Voodoo5, are telling someone using an gf4 with the latest stable nvidia drivers to try a different gfx card? Defend XP if you want but I think you could have came up with a better alternative explanation.
I am here with a much more slower PC than yours (dual Celeron 533, Voodoo5) and I don’t see any of your problems with XP. I think your problem is buggy drivers, or drivers not interacting well with your PC.
These are two token systems from which I’ve taken screen shots. I can certainly take more… these problems are present on every XP system I’ve used which uses any theme with window bitmasks.
> You.. using a Voodoo5, are telling someone using an gf4 with the latest stable nvidia drivers to try a different gfx card?
Sure. He’s got the problem, not me.
And drivers behave differently on different machines. Bugs are always part of the program…
So.. if a geforce4 with nvidia’s own drivers are the issue. Would you say that possibly the issue couldnt still be with XP. Especially since that combination of hardware/software seems to be at the top of the food chain on any other system? Or what card would you suggest? I do have several voodoo2/3’s laying around if you are intrested in buying any. =)
Ok I admit it.. I hate XP.
Isn’t this the same effect as when you took screen shots of bugs in Mozilla 1.1’s XUL rendering? People claimed that was a problem with your video drivers, did they not? Well, do you think it was your drivers, or was it a bug in Mozilla?
The point is the problem exists, regardless of whether or not you’re experiencing it.
Er… Eugenia… not all people had your problems with mozilla, but you said (and I was with you) that YOU had those problems, and that would be enough. But now someone says he has a problem with XP and you says you haven’t any….
You are wrong. I never said that he does not have any problems. Please do not put words I never said.
I SAID that these might be DRIVER BUGS, which are very common. It is more common/logical to *suspect* the driver for these screw ups, rather than the whole GDI of Windows.
Hello everybody.
Is the Gentoo’s (v1.2) X server pre-patched with the SHM?
If no – where can I download if from ?
Thanks for your help in advance.
BR,
Arturas B.
All I did, was to suggest to try another gfx card, which might help him locate the source of the problem. And you guys are attacking me for doing so.
He’s talking about how X11 was originally intended to function with the first statement.
I understand that now, but first read through (of both pages) read like he was suggesting something new. Local speedups have been around for a long time? Guess it is difficult to see if he is reporting or investigating
Quartz certainly is a very nice arch
All I did, was to suggest to try another gfx card, which might help him locate the source of the problem. And you guys are attacking me for doing so.
I did mention those screen shots come from two different systems with video cards from two different but both highly respected video card manufacturers (Nvidia and ATI)
I also mentioned I’d seen the same rendering problem on other systems besides these two.
This is definately a problem with the way XP handles window masks, and serves to illustrate the underlying issues with having clients redraw windows as opposed to the server.
Quartz certainly is a very nice arch … OK so why MacOS X has the same problem than Linux + XFree : “it’s damn slow”.
suggesting buggy drivers for an nvidia card is like suggesting he reboot to see if it goes away. Feh. I’ve seen the same corruption when dragging windows quickly about the screen. Don’t act like it doesnt exist or it’s a figment of his configuration.
OK so why MacOS X has the same problem than Linux + XFree
One word: Aqua
I am not programmer, but I understand mostly of how it works and etc thought. I just check out at BlueEyedOS’s website and it looks pretty insteresting. Is BlueEyedOS stable enough to use as main desktop, yet? Have anyone tried BlueEyedOS, yet?
Thanks for a great article!
Duh me, BlueEyedOS isn’t ready to download… Forget my questions above, I need a sleep.. Nite..
Using the Free generic drivers that came with Mandrake 9.0 at first, I noticed a definite speed improvement when I switched to using NVidia’s drivers.
Obviously this isn’t a solution for this fellow, but this is to say that X performance is most definitely affected by the quality of the driver you have.
I stopped buying ATI cards a while ago becasue of shoddy drivers. I think you might be surprised with the quality difference a simple GeForce 2 (64megs RAM) and good NVidida drivers make.
A500 had a 8Mhz cpu
One I experieced some similar things with Win2k as well as Win98[some years ago]! There’s seems to be a bug or limitation on WinDOZE GFX Resources (Per App).
So if I wrote years ago on SHS-101 ( http://www.s-brandenburg.de/shs-101 ) for Windoze I got a lot of these extraordinary Windoze Behaviour!
Every Button you see in this app was at that point a bmp image resource! Even the knobs (consists of 60 Frames or so) were handled that way! The total number of pictures was about around 300! Sometimes there occured this
strange behaviour.
After days of checking my code without results,
I tried to put all frames of the knob into one larger picture! And it worked …
You can still experience the same thing sometimes with the ppModeler app.
-A
PS:Maybe that I am wrong, maybe that there’s another bug in the WIN32 API.
When speaking of a XFree replacement people usualy mention DirectFB and Berlin, but there’s another vaiable alternative – use DRI. DRI can be separated from XFree (see http://fbdri.sourceforge.net/ ) and OpenGL can be used to draw primitives and copy/blit bitmaps. All the problems that the author mentions are resolved – the communication is as direct as it can get, no useless coversions (most OpenGL implementations are optimized for all supported color formats – not just 32bit), blindingly fast blits(just don’t use glCopyPixels, but textured rectangles) and transparency are supported, the memory of the graphic card can be used to store the bitmaps or alternatively the AGP memory can be used. Also each layer can be rendered into a separate texture so you won’t have to update overlaping regions. And you get lots of new features that no XFree extention can give you.
Yet another good article
This one full of good technical stuff
I wish it was longer though
As for drivers being a issue in XFree. Having a better driver is part of the solution but if XFree had more optomization then every system would benefit including those with bad or good drivers.
I know this is off-topic but what fonts are you using for the windows and the IE on pic “xp3.gif”? How do you get it work like that under IE?. I meant to email you but I was not able to.
Sulvas
Amiga had an 8Mhz CPU, with special chips to accelerate blitting, and a typical Amiga window size, might be, for example, 500×150 at 2 bitplanes. And then, while it was quite responsive considering the hardware, it was by no means “instant”. The Amiga graphics system (Intuition) was incredible for its time, but it’s no miracle, and my system (RedHat 8.0 with a low-latency patch, on a 2.53Ghz, GeForce 4 Ti4200 with nVidia drivers, can, not suprisingly, outperform it. Perhaps it doesn’t outperform it by as much as the jump in hardware would suggest. But, even under X-Windows with GNOME and KDE piled on top, and huge (for example, maybe about 1000x800x32 bitplanes) windows, my windows will glide effortlessly, and artifact-freely around my X-Windows desktop, with instant response. Web pages snap so quickly into my browser (especially under Konqueror!) that I occasionally wonder what’s taking it so long, not realizing immediately that the page has loaded and displayed before I even moved the focus of my eyes from the address bar back to the contents of the web-browser window. I’m all for a faster X-Windows, but at this point it would merely be to reduce X-Window’s CPU usage so that other software might be able to use it, not to speed up the visual speed.
Erik
Erik
A500 had a 8Mhz cpu
Actually it was 7.14MHz, but there were turbo chips that boost it up to ~14MHz.
.. or the ones included in XFree? Because I’ve seen extreme problems with speed on Radeon cards that are not present with other cards with the included drivers.
Secondly, XFree86 4.2.1 (current) is already faster than XFree86 4.1.0 from what I hear.
You might have read an article quoted on /., which points out the fact that our video cards are NOT optimized for system->video memory transfer. The AGP port doesn’t help, since the manufacturer don’t bother about memory transfer from outside.
Guillaume is right when he says that blitting in video memory is really fast. But when you have no more video mem, or when you want to activate opengl, what are the perfs?
On the other hand, what will the perfs of BlueEyedOS be when you will have to draw lines? I understand you want to blit everything. But this way, you will have perf issues when drawing lines (CAO).
http://blueos.free.fr/Static.tar.gz
It’s the missing ‘link’.
Feel free to mirror it as much as possible.
On B.E.OS, lines are drawn in the concerned bitmap,
no perfs issues.
Regards,
Guillaume
>human readable functions like SetTitle(char*), SetSize(int with,int height), SetPosition(int x,int y), Show(), Hide()…
erm, looks a look like BeOS api
Amiga speeds : 7.14MHz for PAL, bit faster for NTSC as CPU speed was slaved to the custom chip’s clock and hence to the video mode.
WinXP: Hmm, not played with XP much, but these look glitches caused by screen redraw not being slaved to refresh or similar – I guess still shots don’t really tell the whole story though…
XFree – yep, X is an interesting system, but on a single desktop, its rather like using a sledgehammer to crack an egg. What is needed is a screen manager that has a simple API and uses efficient methods to render, but can forward draw requests to X where the window is on a remote system, and receive requests/input from a remote system to forward onto te actual screen manager. In other words, make X a wrapper around the screen manager, not a screen manager as a wrapper round X.
I did a few google searches and all I was able to find on installing this was for NetBSD or development info.. so could a kind soul throw me a link explaining this – since I’m apparently to dumb to do it by myself on my trusty Linux…
Guillaume,
On the B.E.OS website I read that windows in ‘normal mode’ are drawn into a shared buffer and blitted to the framebuffer instead of drawing directly to the screen.
This, of course, improves performance.. like said on your site.
But why don’t you submit this back to the XFree project so that everyone can enjoy better performance?
(and it would be even more cool if those buffered windows could be drawn during the vertical synchronisation
Just wondering…
(oh, and pcmiiw)
Guillaume’s notice: Eugenia is not a native english speaker, so please excuse any grammar mistakes.
Sorry, I had to….
Please mod me down
*runs away*
> After days of checking my code without results,
> I tried to put all frames of the knob into one larger picture! And it worked …
Not a huge surprise, there are various hard limits in Windows on the number of windows and GDI objects, both globally and per-process. The actual limits vary from version to version.
MS introduced the imagelist control with win95 to help get around exactly this problem.
I liked this article. I think that reinventing the wheel is stupid. X always was used in high-performance graphic workstations like SGI with Irix.
The only problem with XFree (a particular implementation of X) is imaturity of drivers and lack of tweaks like the autor suggested.
B.E.OS for me is the only BeOS clone that will have a chance to not be only another geek toy. Using the popular linux kernel and XFree will assure that it will have many device drivers. Sorry, but the original BeOS will die because it will not have drivers for future hardware.
XFree project could make a easy “driver kit” and donate to video adapter makers, to incentivate certified drivers.
The only things I can think of that cause those kinds of screen redraw problems are:
1) the system is bogged down (has little/no resources left)
2) One of the windows in the image has stopped responding
Of course, another issue is that a window moved around the screen very quickly will not redraw it’s entire surface while moving or resizing (to preserve resources), so if you take a screenshot in the middle of such an operation, you can get a shot that looks really bad, even though you normally wouldn’t notice the problem at all. With certain types of resources visible in the background, it’s fairly easy to reproduce these types of images on any graphics card with any given drivers, but under normal operation, if your system is not running into resource problems, you wouldn’t notice it a great deal. Whether or not you’re using the standard XP themes should have no affect on this unless, again, you’re running into resource problems (CPU/RAM/vid limitations).
Other than that, a GeForce4MX is NOT a GeForce4 by any stretch of the imagination except in name, it’s just a faster GeForce2MX, which is just a memory-restricted GeForce2GTS. The video card still is not the problem there, as I’m running a TNT2 Ultra, GeForce2 GTS (64MB), and ATI Rage Ultra, all of which rarely display any problems at all, and the TNT2 and GeForce2 are probably running the same driver versions. I also tend to run far more programs at once than are visibly running in those shots (but hey, if you really want to see this on your own system, find an app that kills your CPU and/or RAM usage and then move a window around in front of it).
>But why don’t you submit this back to the XFree project
>so that everyone can enjoy better performance?
Because I use XFree to reach this speed, it can’t be merged, XFree need to be improved/modified as suggested in order to something “interesting”. Improvment must not be ‘on top’ but ‘in depth’.
> Amiga500: frequency 7.14 Mhz
Sure, but my A500 is a custom one
and my Amiga 1200 is powered with a 68060 a 50Mhz!
> Radeon driver
I use the one provided with XFree4.1
> DRI
Nice concept but 3D oriented, I only wanted to cover the 2D part(even if I mentioned that the 3D acceleration solve a lot of issue).
Regards,
Guillaume
Sorry, but the original BeOS will die because it will not have drivers for future hardware.
http://www.yellowtab.com/ – BeOSr5 developed further and will be shipped with alot of new drivers
http://www.bedrivers.com/ – BeOS driver development
IMO, yellowtabs Zeta may keep the die-hard BeOS users until OBOS becomes an option.
People going to Cosmoe/Blue will probably be mostly linux users – often with some previous experience of BeOS
DRI
Nice concept but 3D oriented, I only wanted to cover the 2D part(even if I mentioned that the 3D acceleration solve a lot of issue).
You can do 2D rendering with OpenGL. Just set an orthographic projection and use Vertex2f calls (or for instance use Interleaved arrays with one of the V2F types), draw the bitmaps as textured rectangles( with disabled mipmapping and texture filtering). Most of the GPU silicon is devoted to the 3D core and it will be a shame not to use it. I think OSX Jaguar can use OpenGL for rendering the GUI and Windows Longhorn will use DirectX.
Another DRI advantage is that most 3D accelerators (except the NVidia ones) have DRI drivers that can be easily ported to fbDRI.
This was a pretty good article. I’d just like to add some things on top:
1) Qt and GTK+ don’t use XFree as efficiently as it could be used. They do a lot of rendering, in software, in client space and send a lot of bitmaps to the server. I don’t know what kind of problems drawing lines and whatnot the author was having, but on my system, I get about 194,000 lines per second, a whole lot more than what the author got. In reality, (with good drivers), letting the server do the rendering is a much better idea than shipping a large amount of data through a socket.
2) Quartz’s bites. It has so much potential, using a 100% vector graphics API, but it keeps hundreds of megs of giant bitmaps around. In my Linux install (KDE 3.1-beta2) I can move (and resize and whatever) Windows all I want and there is no flickering or redraw lag in properly written (KWord, etc) applications. And I can actually use all the RAM in my laptop instead of having 640MB just so Quartz runs acceptably.
3) You can’t “install” SHM. It’s already built into every X server. Qt 3.x uses it for some operations (big pixmaps) by default.
4) fbDRI is a great idea. Something like that combined with EVAS and E17 is exactly what Quartz should have been.
Well, by default the MIT-SHM extension is compiled for XFree86. Also if you haven’t been following the XFree86 development lately major changes are coming especially for XFree86 5.0 =)
Check out http://www.xfree86.or/~keithp/talks
Lots of good new extensions being added. In the current cvs snapshots you can now change the mouse cursor and ge shadowing like XP.
-ShawnX
Sorry that should be:
http://www.xfree86.org/~keithp/talks
I’m typing on a blackberry (RIM) 😉
-ShawnX
The Amiga 500 ran a 68000 Motorolla processor at 7.14MHz, not 14MHz. It also came with half a megabyte of ram, although later on this was moved to 1mb and older 1/2mb models could be upgraded to 1mb (the size of an Amiga 500 512kb memory chip was large than a mouse!).
“the size of an Amiga 500 512kb memory chip was large than a mouse!”
Memory CARD, the A501 512K upgrade card to be exact. Brave persons however just soldered the necessary components to the motherboard. With the A500 you could also plug a SCSI adapter into the zorro socket, and gain a 40MB SCSI drive and an additional 4MB of Ram. You can get your A500 up to 50MHz and 32MB of Ram with the Derringer 030 accelerator. I’m a bit rusty, so you may be able to go well beyond that too today.
Any downloadable binary previews yet? Besides screenshots maybe?
(What’s so wrong about open development, heh?)
gybe: OK so why MacOS X has the same problem than Linux + XFree : “it’s damn slow”.
Blame Aqua, not Quartz
Aqua is ridden with eye candy, useless eye candy.
Besides, Bascule, I can’t see your problems on my machine (using Intel 3D, BTW), using IE (couldn’t find the other app on the Net), doesn’t have this problem. I had the same problem as Eugenia on the Mozilla issue, but if weren’t for her, I wouldn’t have realize it (it is so fast, you need to use the Print Screen button to see it).
gelato, can you please expain what a “framebuffer console” is? I understand that a framebuffer is an area of memory (usually on the video card) that holds (one frame at a time) a bitmap of the entire screen that is to be displayed.
I always just thought a console was synonymous with a “terminal window”, an xterm.
You state that you used XFree86 4.1.0 (an outdated version) and the included driver (a driver known for poor performance). Did you at least try out XFree86 4.2.x or the binary Radeon-drivers before you wrote the article about XFree86’s faults?
Some of your speed problems could easily be due to a poor driver.
I’m not saying XFree86 is perfect, but before you write an article about it’s speed, with benchmarks and possible speed tweaks, you should at least have tried to figure out wether some of the problems could be related to your particular setup.
gelato, can you please expain what a “framebuffer console” is?
IMO the term “framebuffer console” is misleading in the context of fbDRI. Probably they named it that way because fbDRI is intendended for consoles that have direct access to the framebuffer (e.g. don’t run on top of X or any other window system ).
The best way to describe fbDRI is – a standalone DRI that works without X.
DRI was designed to allow direct access to the graphic system by bypassing X and most OpenGL implementations on Linux are built on top of DRI.
I see the very same things in XP on a daily basis that Bascule’s examples show. I love how its always “buggy” drivers when theres a problem with Windows but its Xfree86’s problem when it acts slow and not the fact that most of its drivers are written by the video card vendors.
Bascule, the problem (and i understand, cuz your a windows basher!), is that windows xp can use very generic drivers for nvidias and ati’s cards, you can even have bigger resolutions and screens with those drivers (Wich was not possible in previous versions of windows), and all looks like windows detected the right hardware, but make a little research in hardware manager, and you’ll find that it’s then wrong driver for your card.
It happens a lot, people think that windows has detected and installed the good video driver by default, but it did not.
Update drivers, that’s all, and stop making a foul of you.
So, when you boot up a system with fbDRI but no X, you get a “console”? — that is to say, the command line. And from there you can run graphical (OpenGL based) programs that then “take over the console”? Maybe that’s it. Dunno.
I get the impression that there’s too many words here with overloaded meanings: console, terminal, tty, tty0, and xterm.
There are no docs over at
https://sourceforge.net/projects/fbdri/
The fbDRI download is a little over 11 MB, so I’m sure I’ll find some docs in there.
Just loaded up 10 instances of putty. If i drag a putty window over other putty windows the problem appears. If i drag it over other windows (Bersirc, Explorer [not ie]), etc it draws perfectly fine. If i drag over explorer windows with a page loaded, the problem appears as well.
So whats this tell you? That putty and explorer draw slow. They sit too long in their WM_PAINT handler, its not that they aren’t getting the messages or are missing them, or theres some hidden problem with how the gdi draws. They just draw slow. Having written a faked console app (like putty) i can tell you, this effect goes with the territory. Every character is parsed out individually (it supports ansi emulation you know) so.. ta da. Solution? Use telnet.exe instead or ssh.exe from binutils. Sure it happens on all the computers you’ll try it on, until you find a 3ghz one perhaps. At any rate, its the app, not windowsxp.
>> At any rate, its the app, not windowsxp.
And it can be fixed by using those shared buffers
Heck, EVERYONE should use buffers!
Buffers rule!
Buffers make your life smooth!
On XFree4.2 , GeForce4 MX 420
– draw 79500 lines/s
– copy/blit 3360 100×100 bitmaps/s from RAM to FB (or RAM to GRAM)
– copy/blit 18300 100×100 bitmaps/s from GRAM to FB (or GRAM to GRAM)
For the 2 first operations, its 3-4 faster than with the Radeon, but for pure blitting, it’s a bit slower.
Anyway, it changes nothing at the conclusion, XFree is fast
(and faster on GeForce4
) but it needs a lot of improvments.
If you need binaries: http://blueos.free.fr/Static.tar.gz
it’s still faster than any X window manager
Regards,
Guillaume
>> Because I use XFree to reach this speed, it can’t be merged, XFree need to be improved/modified as suggested in order to something “interesting”. Improvment must not be ‘on top’ but ‘in depth’.
I see, I think I misunderstood you the first time..
About the demo:
I’ve made my own demo once (or actually a small wm), which used OpenGL to render its windows.
However, this demo looks like it’s also using OpenGL..
Is this really just plain XFree or just OpenGL?
The Radeon drivers he has are extremely poor. My x11perf numbers (nvidia driver) are anywhere from 3x (in the case of filled rectangle and putimage) to 10x (in the case of lines) as what he shows. Previous benchmarks I’ve done against Windows 2000 show that these totally blow away the GDI (especially line performance) while the blit performance easily matches DirectDraw 7.
Hmm… can’t find the mailing list for fbDRI.
Also, the homepage mentions this:
The dri source code documentation, except for the Jens Owen parts, is pretty bad, with many indirections making it hard to follow. Most of the indirections should be eliminated in FB dri and a monolithic libglfb.so binary created for each card.
After downloading and unpacking, I found that the doc directory only contained a mirror of the homepage. There’s also a Readme containing a couple of email addresses and phone numbers.
Looks like it hasn’t been touched since August 2001. [shrug]
So, when you boot up a system with fbDRI but no X, you get a “console”?
Sort of. You run an application that is fbDRI based from the console. Just like you type startx to run X. That application can be for instance quake or a full-blown window manager(with many GTK, QT and B.E.OS apps running on top of it). That window manager will use OpenGL to draw lines and rectangles and blit bitmaps instead of using the X Window System API.
In fact, it is much more like to be a driver issue, simply because Nvidia has ALWAYS sucked when it comes to 2D, sure they get great 3D, but 2D is just pure and utter crap when you are with nVidia.
Hmm… can’t find the mailing list for fbDRI.
….
Looks like it hasn’t been touched since August 2001. [shrug]
Yup, it looks like the project is not active currently. It’s still a nice proof of concept – that DRI can be made to work without X. And a base for porting other OpenGL drivers (besides the Radeon one) to work without X.
fbDRI is not realy required. The standart DRI + OpenGL on top of X can also be used to implement a window manager. It’s just that X will be an unnecesary burden.
I love how its always “buggy” drivers when theres a problem with Windows but its Xfree86’s problem when it acts slow and not the fact that most of its drivers are written by the video card vendors.
Am I wrong in thinking that nVidia makes the drivers I use on any given platform (except those that they haven’t released drivers for)? I found a long time ago that if I used the drivers that either Windows or the graphics card manufacturer (as opposed to nVidia) supplied, the version was much older than the reference drivers, and performed accordingly. For most people it’s not a big deal, because the basic drivers do well for 2d graphics, but once you get into 3d you really have to have the latest drivers from nVidia to get the best performance.
n fact, it is much more like to be a driver issue, simply because Nvidia has ALWAYS sucked when it comes to 2D, sure they get great 3D, but 2D is just pure and utter crap when you are with nVidia.
I thought it was shown a while back (when the GeForce4 was first released) that nVidia 2d problems were due to the hardware that graphics card manufacturers were using for the 2D rather than anything that nVidia was supplying (the graphics chip itself and the drivers). Now if I could only remember which company made the cards that showed this so I could point out the reviews…
http://blueos.free.fr/Static.tar.gz is plain XFree.
Feel free to send me your OpenGL wm, in order to
see if it’s “fast enough”.
Regards,
Guillaume
Ok.. per Marios comment about beos nd clones are doomed to being “geek toys”.
I gotta ask, WTF is that? What does that mean? Not long ago, home computers PERIOD were considered “geek toys” to the uninterested masses that didnt bother to educate themselves to the real implications of home computing. I really can’t quite grasp what people are trying to say when they dont understand something and start tossing “geek toy” or “hobby OS” labels around. Besides, as this site, and others, show via the fiscussion boards, the world is full of geeks. So if something is a geek toy, it has a pretty good chance of being popular in a real sense. For example, the Matrix was a horribly stupid movie, but it had geek appeal, and was quite popular.
Further, what is the flipside of “geek toy”? Is it something along the lines of “used by non-geeks the world over…”? So then i suppose shoes must not be geek toys. Oh, and I guess Windows is non-geek toy. So that must mean that in order for something to be taken seriously, it has to be windows. Weird
Guillame
Great story , nice to read a technical article by a coder with facts represented
within the article .
good luck with the b.e.os Project, im looking forward to using it on my xbox
Bascule I agree with the initial post you made, looks like a bug and not a draw error.
Eugenia I’ll happily buy that dual system from you With the voodoo5 card..
and again … i agree… its your site.. …people
should try to keep the comments
on a more professional level, discussing matters in a way that will spawn a greater/better development cycle!
geleto *cough EVAS cough*
rajanr one of the apps bascule is using is “putty” an ssh telnet client
Guillaume, what x11perf options are you using? I’m using an MX-440 (just a hair faster than your 420) and I’m still getting numbers twice as high as yours.
x11perf -line500 : 194 K/sec
x11perf -shmput100 : 7 K/sec
x11perf -copypixpix10 : 1750000 = 175 megapixels/sec
x11perf -copypixpix100 : 39.5 K/sec = 395 megapixels/sec
x11perf -copypixpix500 : 1.9 K/sec = 477 megapixels/sec
I’m using an optimized Gentoo server, but that shouldn’t be a major factor. The only thing I can think of is that my processor is a lot faster (2GHz P4). Since this is an accelerated test, however, the processor shouldn’t be much of a factor either. If the 2x performance difference was because of processor speed, then the server would have to be 100% the bottleneck, which not only seems unlikely, but isn’t supported by the data. The results show that the card itself seems to be bottlenecking at 500 megapixels per second. Also, the 10 pixel case has excellent performance (given that it requires 50 times as many commands to be sent to the card as the 100 pixel case) seems to indicate that both the Xserver and the client-server link are fast enough to drive the hardware at maximum performance.
Thanks for the static binary. Do you have a link to the source so that I can play around with it?
Thanks.
I used :
x11perf -putimage
x11perf -line500
X11perf -copypixwin
From Redhat7.3 (XFree4.2) with NVidia drivers
(Yes, I wanted to play Unreal2003
)
on a Pentium4 (512k of cache) at 1.7Ghz
with a GeForce4 MX 420 64MB DDR.
Rayiner Hashem, could you give me your first impression of the ‘binary’, even with twice raw perfs, you will ‘see’/feel something the issue of XFree.
Xfree86/x11/wm/kde/gnome/qt/gtk+
Layer on Layer on Layer.. That’s why it sucks!
Does anybody know any good links to docs about the architecture behind XFree86/X11?
I am bit curious about how the Windowmanagers in X11 works.
Yes, I know, it’s got nothing to do with the performance of X, but it struck me while reading this article and the interview with the RedHat people.
Why doesn’t X do sound?
Think about it: Although it’s called a graphics system, X is really more of a terminal system. After all, it handles not only graphics, but also input, just like basic Unix terminals have text output and input.
Surely on a typical desktop machine with speakers, those speakers are part of the “terminal” – hell, there are monitors with in-built speakers!
So X should acknowledge the fact that terminals today no longer look like terminals a decade ago and handle sound as well. It’s the most logical solution, and it would really solve a number of problems that have appeared, such as the multitude of sound system, the permission on /dev/dsp and things like that.
Of course, that’s unlikely going to happen :/
>>XFree86 4.1.0 (an outdated version) and the included driver (a driver known for poor performance).
not to mention in mdk 9 everything is compiled with gcc 3.2 and that alone makes a huge difference in performance. I have it installed on 3 machines (amd 1ghz 512 ram, dual pII 400 mhz 256 ram, laptop pIII 500 mhz 256 ram)
I have seen huge performance gains over mdk 8.1 in the whole system.
and isn’t the new glibc 2.3 supposed to also help with performance?
not to mention stuff in the kernel like the preemp and low latency patches (not included in mdk 9 i don’t think)
there is more to performance than just X (though X does need a lot of work)
I thought (like most here) that he was having a problem with his video card drivers. But I tried it too. I can replicate the same problem here. I have Asus GeForce 3 Ti200 (using latest driver)
I only opened 8 notepads, My Computer and Outlook XP. Then wiggled around the My Computer window. It left some controls unpainted… Very interesting…
Um, you have no clue what you’re talking about. The layering is as follows:
Application -> Toolkit (GTK+ or Qt) -> xlib -> Xserver.
That’s the same layering as in any other OS. Take Windows.
Application -> Toolkit (Common Controls) -> Win32 -> GDI.
And the same in OS X.
Application -> Toolkit (Aqua) -> Quartz -> lwwp (light-weight window process).
The WM appears nowhere in the layering. It’s a third part that controls window movement. It only comes into play when moving/resizing windows. As for other layers (for example glib in GTK+) those support libs are there in the Windows and Mac toolkits as well, but because GTK+ development is open, you get to see what stuff they use to implement the functionality.
Why doesn’t X do sound?
There is NAS, the Network Audio Server, which is exactly what you want. http://radscan.com/nas.html
-fooks
See all…
Firstly…
Guillaume and I, several times posted some comments about the news that appear here.
WE NOT HAVE any formation about the english language. He speak FRENCH and I PORTUGUESE! I learned english reading books and navigating in web. In Brazil, the things are harder. Our country is poor!
I come from a country that the languages like french, portuguese, italian, spanish and arabic MIXED. Here we have a true desorder. Then, please, I’m not wanting begin a war about this issue and teach a cleric pray too! YOU ARE NATIVES, we not!
Secondly….
Thanks for all that believe in our work and contribute of any form!
Want know more? JOIN US!!!!!!!!!!
Michael Vinícius de Oliveira
BlueEyedOS Webmaster
This is totally off-topic, but since you both were bringing it up at the beginning of the long line of posts, I figured I would ask.
As I said the other day in a different post, after a few years of not using Windows, I am using it again for a project I’m currently working on. I installed XP and Office XP. The screen redraw problems that Bascule has illustrated are a huge issue for me as well. If I open a Word XP document with graphics in it, I cannot see them since they become “squashed” into piles of colorific goo. The only way to correctly view a graphic in Word is to center the graphic in the window and then hit the maximize or restore button. However, once I start scrolling through the document again, it screws up the graphics and surrounding text again. I have Windows installed on 3 machines, each with a different video card (3dfx Voodoo3, ATI Radeon 7500, and GeForce 3 Ti) and have the same results on all three; even after updating all the drivers.
I am not sure what the problem is, but it is very annoying. If either of you figure out how to fix it, please let us all know since I’m sure there are others out there who are kicking XP for the same reason.
There is NAS, the Network Audio Server, which is exactly what you want.