> -----Original Message----- > From: Alan Cox [mailto:[EMAIL PROTECTED] > Sent: 13 June 2004 20:04 > To: [EMAIL PROTECTED] > Cc: Jon Smirl; Eric Anholt; Alex Deucher; DRI Devel; > [EMAIL PROTECTED] > Subject: RE: [Xorg] DRI merging > > > On Sul, 2004-06-13 at 20:47, Matt Sealey wrote: > > Linux basically falls behind on two simple fronts at the moment: > > it has no "simple" 2D or 3D framework capable of much more than > > I deal with embedded Linux people on a daily basis. I think they would > disagree. For 2D it has several in heavy use > - Keith's tiny X server work > - Nanogui (2D down to about 50K RAM) > - DirectFB (particularly strong at multimedia) > > For 3D you end up looking back at the mesa-solo work and it shares that > same interest with the X over mesa people.
Agreed, but DirectFB doesn't work with Qt, and the company I work for has a perfectly good OS for multimedia work (http://www.morphos.net :) > > We need a low-level "kernel" graphics API (much like Windows > > Unfortunately for a lot of hardware the entire design is different per > card. You have to deal with an incredible range of hardware and its a > tribute to the X DDX and XAA design how well it has coped with this. Fortunately we have APIs like OpenGL to relieve us of the front end API worries. What you do in back.. well that's up to the author and card vendor. As long as there is a simple API for it all (I could mention VESA as a good example of 2D acceleration that works and is still in good use and practice..) that does everything everyone could expect. 2D graphics have hit a peak now, I dare say it's not going to improve beyond the current acceleration features specified by modern APIs (of which GDI+ and the X Render extension are probably the most current "bitblt" and geometry APIs and still state of the art after how many years?) What remains is to build on top of an advancing 3D API - which offers silly but useful tricks as using the Z-buffer and/or stencils to order windows, thereby eliminating overdraw and layering in a single swoop. That alone raises the efficiency of windowing systems. We have currently got something which is halfway between what we had and what people want - 2D APIs based on framebuffers and DRI support for 3D layered on top - and they restrict everyone not using X to a full-screen 3D environment. What I am talking about is an environment where you can use 2D without having a 3D card (re low end like ATI IMAGEON..) but also implements 3D in a "desktop" way - like you can put Mesa output in a window under X, you should be able to portion your display and run multiple accelerated 3D applications in different sections. Borders on windows? Up to the OS and user! :) > Secondly every line of code you put in the kernel has to be audited, > analysed and can introduce security holes or crash the machine. Its > harder to debug and its harder to write in the first place. There are > very good reasons (see the original DRI paper) for putting as much as > you can in user space. The Mesa X work also tries to keep as much as > possible in user space - including designs for mode computation by > kernel->user callback. Userspace would be just as good. I'm not sure how much it really matters these days in the world of 3.2GHz processors, 10 gigabyte per second data buses, and GPUs with more power than the CPU, but at one point userspace graphics was dog slow. I am from a world where we use stuff under a Gigahertz, low power, low cost, i.e. not a $3000 gaming box on every desktop. When someone comes along and says they want to make a cost-reduced console based on Linux, it should be possible, not laughable, for instance.. ;) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
