[Fresco-devel] Re: Lots of Video drivers. (te quieres hw acceleration?)

On Thu, Sep 05, 2002 at 04:53:55AM -0700, J. Imlay wrote:
> 
> Hello,
> 
> I have read most of the stuff on the berlin projects web sight (well I
> shouldn't say most, but a lot of it) and I really don't know what to
> think of it, in particular, I like everything but the SVG that just
> doesn't make cence, pixel based is a good thing. It might just be the way
> I think about things. If you could explain why, or because you are
> probably quite busy, tell me where I can find why, I could possibly change
> my mind about the next bit.

Regarding SVG: not using vector graphics just doesn't make sense :-)
There are several related reasons, at different levels.  One is simply
aesthetic -- vector graphics can be anti-aliased, cleanly rotated, and
generally made to look nice.  Of course, all this can be done with a
pixel-based server as well, but only if the app does it by hand --
which takes us to the next point: apps are all in vectors anyway --
they're full of straight lines, smooth curves, gradients, text, and
so on.  This stuff starts out in vector form, and while you can cache
the raster versions, it makes them non-editable -- so someone has to
keep track of things in vector form anyway.  It could be the server,
or it could be a client-side toolkit, but it has to be done.  And it's
more efficient to do it in the server, and in Fresco we render
everything in the server anyway (there is no client side toolkit), so
it has to be in the server, so we might as well be the normal mode of
operation.  Then there're technical reasons -- vectors are strictly
more powerful a representation than rasters, in the sense that
anything you can do with a raster you can do with a vector, but not
everything you can do with vectors can you do with rasters.  In
particular, you can take advantage of hardware acceleration, and you
can render at different resolutions (which is going to be massively
important within a few years, once IBM starts producing those 300dpi
monitors they've been working on -- I have a suspicion the main reason
this sort of thing isn't available yet is that Windows/MacOS were
still raster-based, and therefore couldn't handle that kind of
resolution).  Finally there are the architectural reasons, and these
are in some sense the most important -- because everything on the
screen is vector based, we can freely embed chunks of the scene graph
in each other, and rendering, event handling, and so on, all work
seamlessly.  This would be nigh-impossible to handle elegantly or even
accurately with a raster-oriented setup, and the ability to endlessly
layer and embed pieces of apps is central to our architecture.

Oh, and we get resolution independence, so you can display things in
real sizes, which fixes a really stupid UI misfeature.  There's _no_
reason upping your resolution should shrink your desktop, and if you
want more screen estate, vectors let you simply shrink everything on
the desktop, whether you raise your resolution or not.

So, uh, I'm not really seeing any arguments on the pixel-based side of
things, but maybe you have some?  :-)

> I am working with the XFree86 Drivers and creating an abstraction layer
> that is like Xfree86 with out X. In otherwords, it uses the XFree86 binary
> video drivers and hardware acceleration, but it's not a program, it's just
> part of a larger project I am toying with. (a micro kernel based windowing
> system, for me. And who ever else likes it if such peoples exist)

Neat.

> What I'm offering is to work with you or whoever else on your team
> that would be more appropriate, to get the level of hardware support
> in Berlin EQUAL to that of XFree86, and keep it there. (this
> includes both 2D acceleration and 3D on hardware that supports it,
> but I don't know much about the 3D because it's so muckied up with
> GLX) You probably all ready know this, but that gets you aframe buffer
> with what ever supported acceleration features that particular driver
> offers.
> 
> Does this seem like something you'd be interested in?

Definitely something we're interested in, though perhaps we're not the
people you should be talking to directly.  Our general policy has been
to target whatever drivers were around (currently SDL and GGI are
well-supported, with some buggy support for GLUT, DirectFB, etc.), and
we'd generally like to avoid the way X sucked all graphics support
into itself, so that the only way to get decent graphics is to run
under X.  (_Why_ do Quake etc. require X?  Loading up X just to play
a full-screen game that needs all the memory/CPU it can get is
absurd.)

So our ideal architecture would have one library/framework/whatever
that provides good, solid, accelerated graphics support on the
console, that we could then use like any other program.  This way
everyone gets decent drivers, we get to spend our time thinking about
widgets instead of control registers and DMA buffers, and we don't
even have to run the server as root.

On the other hand, we'll take whatever we can get :-)  You might
consider talking to the KGI guys (kgi.sf.net), who have been working
on providing a real kernel-based graphics framework for years, but I'm
not sure how they're doing these days, and it sounds like your plan
could provide payoff rather more quickly than theirs, so don't let
their existence stop you.  Another possibility is that you should be
working those graphics drivers into a GGI backend, GGI already being
quite portable with a clean API -- that might benefit a lot of people
besides us.  Or, if none of these are viable, for whatever reason, I'm
sure we'd be interested in targeting the drivers directly; we're
already set up to plug-in new driver backends, so this wouldn't be
all that hard.

Good luck.

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein

This email may be read aloud.