On Friday 06 May 2005 06:05, Tim Long wrote:
> Quoting Hugh Fisher <[EMAIL PROTECTED]>:
> > 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.

For offline-rendering maybe. Not for the desktop.

> 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

Have you even seen stuff like Mac OS X or some of the fancier experimental 
window managers for X? If you had, you would realize that this so called 
eye candy already uses fully 3D effects *today*. There's no way you can do 
this stuff in a 2D pipeline.

> 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. 

This is purely a software problem. It's way better to just fix the crappy 
scheduling in the software than to bloat the hardware with stuff nobody 
needs.

> 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. 

And nobody needs more than 640KB RAM.

> 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.

We have these extremely powerful and cheap graphics coprocessors in 
basically every PC out there. Why on earth do you insist on software 
rendering? It just doesn't make any sense.

cu,
Nicolai

Attachment: pgpNIJPu26rFh.pgp
Description: PGP signature

_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to