> Any ideas on how Windows(-doze not appropriate here) does it?
It doesn't go through the net ?
> On exactly the same hardware and a configuration of 2x2 screens,
> 1024x768 each, and 24 bit color depth, everything works wonderfully
> smooth as if there was nothing to it.
Wait - we now have to clarify what hardware you are running on and how you
do it.
As you say Windows does it, I assume all graphics cards are local to the
machine - right ?
Then X should be fast, but only if you don't bog it down with e.g. using the
tile target.
X - or rather XGGI has two nasty limitations:
1. It needs a directbuffer
2. It needs to run in SYNC mode
So if you use the tile target, you have to use "usedb". This causes the tile
target to allocate a large membuffer to simulate a directbuffer. As it has
no idea about where the db gets changed, it has to blit out the whole buffer
whenever it gets a ggiFlush().
Now XGGI is ASYNC as well. This will automatically trigger a full ggiFlush()
every 1/FPS seconds. That of course takes tremendous amounts of bandwidth on
the memory bus and the associated CPU time for copying stuff around.
Say you have 1024x768x32bit - this gives 3MB per framebuffer. At 25 FPS you
would be pushing 75MB/s over the PCI bus, for 4 framebuffers you get
300MB/sec, thus exceeding the bus limits.
However what you can do easily with local framebuffers is, to use the
multi-screen mode of XGGI:
-targets targetlist the target(s) we should open the screen(s) on
-modes ggimodelist the mode(s) we should use
-rows number of screen rows in multihead configurations
This allows to build multi-screen configurations without that much overhead.
However I got to check how X handles these. AFAIK, while they logically form
a grid (you can move the cursor between the tiles), they do not allow to
place windows across borders (got to test that again ...), which makes this
mode unsuitable for many possible applications.
> 1-2 per cent cpu load. Launching some graphically intense
> applications results in 6-7 per cent cpu load. Is the graphics
> functionality maybe ASYNC in Windows?
No, it's just not doublebuffering like the tile-target solution. It's more
like the X multi-screen feature. Windows is using SYNC mode for drawing, but
that doesn't matter on an inherently SYNC target, like a local framebuffer.
It just has a native logic for spreading stuff across multiple displays
right from the start instead of emulating it using a tile-target-like
technology.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
