AW: AW: AW: Creating a planetarium using Ruby

[Unger R. <ric...@te...>]

=20

> -----Urspr=FCngliche Nachricht-----
> Von: Helge Hafting [mailto:hel...@ai...]=20
> Gesendet: Donnerstag, 16. M=E4rz 2006 09:16
> An: Unger Richard
> Cc: lin...@li...
> Betreff: Re: AW: AW: Creating a planetarium using Ruby
>=20
> Unger Richard wrote:
>=20
> >Hi!
> >
> >I don't really know, because I have not tried, but I think=20
> the problem with smooth Animation across 20 Screens in one PC=20
> is the bus speed.=20
> >
> >The PCI bus can transport 127MB / sec.
> > =20
> >
> If it is a 32-bit 33MHz bus.  (133 MB/s, but some is lost to=20
> overhead.) There are also the more expensive 64-bit 66MHz=20
> bus, that gives you
> 4 times as much, 533MB/s minus overhead.
>=20
> >Lets assume you run each screen at 1024x768, 16 bit =3D 1,5MB / =
screen=20
> >Now 20 Screens is 30MB of data, 127MB/30MB ~ 4, ie you could=20
> (theoretically) drive the screens at 4 fps.
> >
> >That's not exactly smooth animation.
> > =20
> >
> Sure not.  One could display nice very high resolution images=20
> though. :-) But throw in a server board with two of those=20
> 64-bit buses, and you could hit 32 fps in theory.  Well, if=20
> you can find dual or triple screen cards for 64-bit pci that=20
> is. Gamers might not be impressed with 32 fps, but it beats=20
> movies at least.

Yeah, finding those cards might be tricky... I'm not aware of any GFX =
Cards for 64bit PCI - they went the way of AGP...
But I agree that it seems possible in theory. One would have to try it =
out though, and above all, identify apropriate products that provide the =
needed features.

>=20
> Some cards have mpeg decoders on them - this will allow large=20
> bandwith savings when playing prearranged video/animations. =20
> I am not sure mpeg for 20 screens could be generated in realtime.
>=20

Here the problem is that you would have to "split" your MPEG across =
multiple screens - that does not seem like a trivial task to me. If you =
started with a single MPEG file, you would have to calculate which parts =
of the image fall on which screen, split the parts, scale and distort =
each part appropriately, recode the parts into seperate MPEG streams and =
then send them to the different MPEG devices... ugh.

> >Now I freely admit that calculation is simplistic. In a=20
> modern computer some of the screens would be connected to an=20
> AGP bus, some could be connected to PCIe. Some boards might=20
> include more than one PCI bus, meaning the cards don't all=20
> have to share the 127MB...
> >
> >Still, until I actually tried it out, I would be worried=20
> about trying to move that amount of data (all screens more or=20
> less in sync!) on Pc-type hardware...
> > =20
> >
> No guarantee that one gets near the theoretical limit. :-/=20
> The synchronization should be simple, just take care to=20
> update the screens in sequence.
>=20

Again, I contend it is not that simple - because you would have objects =
moving from one screen to the next, the different screens would have to =
be synchronized to prevent the objects from tearing as they crossed =
screen boundaries. (Isn't that what they call "Genlock"?) This requires =
some kind of synchronization signal for the screens and GFX cards...

Richie

>=20
> Helge Hafting
>=20