JW> I'm just concerned that the DGA extension will be removed with
JW> no adequete replacement. The main issue with DGA seems to be the
JW> way it requires root privs and can write to other parts of
JW> memory. Can we not have some sort of "/dev/dga" device or is this
JW> not the place to ask ;) is this not feasible?
James,
I'm rather sympathetic to what you're trying to achieve (and I do know
other legitimate applications for DGA), but unfortunately it can't be
done. What Mark is speaking about is the added complexity to drivers
to allow direct access to the framebuffer and synchronise with the
client. Doing that through a device won't simplify matters.
If you're working with small updates, you should be going through a
shared mem pixmap and using ShmPutImage. Yes, this will cost you one
extra copy (from your app to the shmem segment, and then from the
shmem to the framebuffer), but that should not be noticable on modern
hardware (which can typically push half a gig per second). If you do
things right, you should be able to render directly to the shared mem
segment, which will avoid the first copy.
As an additional data point, I'd like to refer you to the shadowfb
code, which basically introduces an additional buffer in the server
and pushes all screen updated through that, basically what you'll be
doing with a shmem segment. Experience shows that the shadowfb code
is sufficiently fast in all cases, and actually faster than any form
of direct unaccelerated rendering (except for filling areas).
Juliusz
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
