Oh yes, many ways. DGA1, DGA2, Linux Framebuffer, plain X, X11Shm (Shared memory extensions), then we of course have DirectFB and lesser known KGI/GGI...
However, that's all a bit moot, since you probably DON'T want to send the images to a framebuffer anyway. You'd want them to end up to the overlay surface, to take advantage of hardware colorspace transform and scaling. With mplayer there are even several routes to take:
Vidix, mplayer's own kernel drivers for certain graphics card. mga_vid, mplayer's own kernel drivers for matrox cards, provides hardware acceleration in both X and in console mode And finally, Xvideo, which is part of X. The first two mentioned are a bit faster than Xvideo, and atleast mga_vid gives you tripple buffering as well.
Of course this is only AFTER you've decoded the image, the number of ways an.avi or quictime.mov could be encoded, the multitudes of audio and video codecs that could be used is only limited by the fourcc, which would allow for, what, 2^32 different video codecs atleast?:-)
However, " The platform dependent part implements a 2D-graphic drawing canvas which is used by the platform independent parts.".
This rendering model, that the client renders widgets and sends the resulting pixmaps to X, is what makes X seem so slow, IMO. What we need to do is have a way to tell X to "Render a button at X,Y", instead of "put this picture at X,Y". With the former, you can benefit from 2D acceleration more than with the latter.
I timed Windows XP on a 1200Mhz Celeron vs. Xfree3.6 on Linux 2.2.18 (Redhat 6.2), Pentium, 133 Mhz.
Opening IE (On XP box, obviously): 4 seconds Opening Netscape (on Linux) box: 3 seconds
Of course, Netscape 4.7 is perhaps lighter than IE these days...
Benchmarks are wholly useless, it's not X's fault openoffice is slow;-) Openoffice, I believe, is also written in java, which will not benefit from 2D acceleration at all (well, Sun Java 1.4.x claims to be able to do some 2D acc, but I doubt openoffice can benefit from it).
Yes, there is a problem. The problem is us hu-mans. Actual performance and perceived performance differ, while the Linux kernel is tuned for high performance and throughput, interactivity suffers (i.e. perceived performance on a desktop system). The patches tune the kernel for interactivity instead of throughput, which increases the perceived performance.
If there was only a patch for hu-mans, too, to fix all this nonsense about perceived performance...
Xine rarely even plays a DVD, let alone display any menus of any sort for me, it seems to prefer deadlocking or crashing, even with Unencrypted DVD's!! MPlayer plays DVD's flawlessly though, mplayer -dvd 1, and it immediately plays, or decrypts and plays on the fly, without any need to click on icons in an unrealiable GUI which seem to alias half of the buttons with 'deadlock now', creating a virtual maze of "good" and "bad" buttons to click in the right order for anything to play.
Slashdot Mirror
Oh yes, many ways. DGA1, DGA2, Linux Framebuffer, plain X, X11Shm (Shared memory extensions), then we of course have DirectFB and lesser known KGI/GGI...
.avi or quictime .mov could be encoded, the multitudes of audio and video codecs that could be used is only limited by the fourcc, which would allow for, what, 2^32 different video codecs atleast? :-)
However, that's all a bit moot, since you probably DON'T want to send the images to a framebuffer anyway. You'd want them to end up to the overlay surface, to take advantage of hardware colorspace transform and scaling. With mplayer there are even several routes to take:
Vidix, mplayer's own kernel drivers for certain graphics card.
mga_vid, mplayer's own kernel drivers for matrox cards, provides hardware acceleration in both X and in console mode
And finally, Xvideo, which is part of X. The first two mentioned are a bit faster than Xvideo, and atleast mga_vid gives you tripple buffering as well.
Of course this is only AFTER you've decoded the image, the number of ways an
I stand corrected.
However, " The platform dependent part implements a 2D-graphic drawing canvas which is used by the platform independent parts.".
This rendering model, that the client renders widgets and sends the resulting pixmaps to X, is what makes X seem so slow, IMO. What we need to do is have a way to tell X to "Render a button at X,Y", instead of "put this picture at X,Y". With the former, you can benefit from 2D acceleration more than with the latter.
I timed Windows XP on a 1200Mhz Celeron vs. Xfree3.6 on Linux 2.2.18 (Redhat 6.2), Pentium, 133 Mhz.
;-) Openoffice, I believe, is also written in java, which will not benefit from 2D acceleration at all (well, Sun Java 1.4.x claims to be able to do some 2D acc, but I doubt openoffice can benefit from it).
Opening IE (On XP box, obviously): 4 seconds
Opening Netscape (on Linux) box: 3 seconds
Of course, Netscape 4.7 is perhaps lighter than IE these days...
Benchmarks are wholly useless, it's not X's fault openoffice is slow
Yes, there is a problem. The problem is us hu-mans. Actual performance and perceived performance differ, while the Linux kernel is tuned for high performance and throughput, interactivity suffers (i.e. perceived performance on a desktop system). The patches tune the kernel for interactivity instead of throughput, which increases the perceived performance.
If there was only a patch for hu-mans, too, to fix all this nonsense about perceived performance...
Xine rarely even plays a DVD, let alone display any menus of any sort for me, it seems to prefer deadlocking or crashing, even with Unencrypted DVD's!! MPlayer plays DVD's flawlessly though, mplayer -dvd 1, and it immediately plays, or decrypts and plays on the fly, without any need to click on icons in an unrealiable GUI which seem to alias half of the buttons with 'deadlock now', creating a virtual maze of "good" and "bad" buttons to click in the right order for anything to play.
SETI@home is programmed in Ansi C.