Quoting Hugh Fisher <[EMAIL PROTECTED]>: > > On 05/05/2005 06:24:04 AM, Jack Carroll wrote: > > Here's one possible reason. > > Some video card applications, such as desktop publishing, > > don't > > require any acceleration whatsoever. The simplest possible logical > > interface that will let the X driver write to a high-resolution > > framebuffer > > is enough. The image sharpness and color accuracy of the analog back > > end > > are the only things that market cares about. > > Software-only rendering was discussed at a talk by Keith > Packard, long time X guru, at LinuxConf 2005 a fortnight > ago. He said it's just not workable anywhere outside the > PDA market. Modern GUIs spend a lot of time shuffling > pixmaps - windows, icons, etc - around, and without > hardware acceleration this is viewed as unacceptably slow > by the majority of desktop users. (As PDAs get bigger > screens, they'll go the same way.) >
I would disagree with that statement. IMHO Software-only rendering will still be inportant in the future. I am not an expert, but with my limited understanding of graphics chips I believe that with the new demands being placed of graphics by the eye candy crowd that that any professional level card will need a 2D engine independant of the 3D/OpenGL pipeline. This is because a professional level card will need to be able to run an openGl thread and the eye candy simultaneously in the new graphics enviroments. Otherwise your OpenGL app and your anti-aliased xterm will become bogged down as the former and your X server fight over control over the graphics pipeline. One way around this problem is that when an opengl context starts then the X server will fall back to software rendering. A consumer level card will probably not need such a facility as Joe Public will either be running desktop publishing or a full screen game, not both simultaneously. I suspect that modern CPUs are fast enough for software rendering if double buffering is used by the X server. I main home computer is a SGI 320 which has a unified memory design with the the graphics system intergrated with the main memory system (so no bandwidth constraints or latency delays copying data to video/frame buffer ram over AGP/PCI). The Linux graphics drivers only support frame buffer (not even a hardware cursor). Yet a PIII 833 can make quite a snappy experience for X. The software rendering only become apparent when you scroll a window or the text console scrolls a lot of information. If we had hardware acceleration of the cursor and bitblt then anyone using it wouldn't know the difference. Then again I could be displaying total ignorance of the subject. I should post a query to the Xorg mailing list and see whether someone can enlighten me (or a flame war erupts). My 2c worth. :). Tim. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
