[openbeos] Re: openbeos Digest V1 #118
- From: Mark-Jan Bastian <markjan@xxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 19 Dec 2001 11:58:14 +0100
On Wed, Dec 19, 2001 at 11:16:14AM +0100, philippe.houdoin@xxxxxxx wrote:
> > Also, I'm not sure if today's
> > videocards can actually do that amount of 2D acceleration.
> > They can do screen-to screen blits, but can they do that with
> > the full 128 or 256 MB of videoram too?
> > Can they combine data from n bitmaps simultaneously
> > and blit it to the framebuffer ?
> > Are there any guys on this list with the OpenBeOS app_server
> > development who can comment on those issues ?
> I'm not from OpenBeOS app_server team, but, based on DRI graphics
> chipsets code, I would state yes you can. Recent 2D/3D GPUs can manage
> multiple offscreen areas in their videoram, and you can ask them to blit
> from offscreen to screen, or the reverse.
> Compositing offscreens areas themselves or with screen one?
> Not sure, maybe using rasterization paths of their 3D hardware engine
> could works.
That's a cool idea too - make every bitmap / window just a polygon with a
huge texture, it's own transparency etc. You can then fold up windows by
turning it into a lot of polygons, and carefully offsetting the
same window content texture/bitmap of every one of them, and then
manipulating the polygons of the window.
Then, instead of moving a square window around, you can manipulate all
polygons of the window in any way you like, and crunch them like a piece
of paper, dropping it into your trashcan...
The textures are not allowed to be compressed in that case. Also, if
there are a lot of caches of textures in the chip itself, and you
want to be able to blit a live bt848 videostream from another PCI
chipset, you also need a way of synchronising that blitting and
the 3D rendering process on the videocontroller. I'm not sure if
that is possible on todays videocards.
> But, AFAIK, basic bitmap compositing (blending) in Quartz is done by the
> CPU (altivec-engine), not by GPU. Maybe Apple would push this into video
> card somedays... But, before, they need to train their package builders
> team to shell scripting ;-)
Hehe :) Personally, I don't really like scripts that configure,
install other binary software. It's often used as glue to match
interfaces in a kind of crude way. They also contain a lot of state
that dumbly configures things sequentially. That's okay for
just copying files from a to b, but anything more advanced will
grow in lots of directions - state being stored and communicated
in any way the programmer prefers that day. It's very flexible,
sure, just as flexible as a seacontainer full of various hoses and
connectors without documentation ;)
On BeOS, connectors and hoses are wel thought-out. You write a PCI
driver, which loads it's support modules itself, and publishes all the
devices it supports. You can use a node monitor on the application level,
and use that to detect a new device.
There is no user-space polling in the whole chain, and there are no
scripts that have to be ran to configure the device. It makes perfect
sense in the modern PnP days. There is no script to be seen, and
installing is as simple as having the needed files on your harddrive
at a fixed location, and running your application.
Mark-Jan
Other related posts:
