FB-access-wrapper?

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Cox wrote:
| On Sad, 2005-01-15 at 10:47, Thomas Winischhofer wrote:
|
|>And as regards Keith's question: No, generally not. But the shadow code
|>submits very small areas and refreshing small areas is painful due to
|>the USB transfer overhead. Now I "collect" the areas by building a
|>"large" area covering all the small areas RefreshArea() got in the
meantime.
|
|
| I would have expected the merging to be dependant on the difference
| between the area updated that has changed and the area updated that has
| not. A single "collection" will generate very bad results on things like
| diagonal lines across the screen when it should generate a set of boxes.


"Boxes" are a desaster to update on this device, since that requires a
line-wise copy.

I started out with a primitive RefreshArea() function similar to the
ones in .?_shadow.c. Bad, worse, worst. Unusable.

Second step: I updated the whole area starting from x1/y1 up to x2/y2,
ie all *entire* lines inbetween. Slightly better, but impossible to work
with since RefreshArea() is still called too often, and very often with
small areas.

This final solution, as described earlier, is perfect.

A large update can run mostly asynchonously since the kernel driver has
a quite big buffer. Data copy requires setting up a transfer to a
certain endpoint, and then sending the data to another endpoint. If I
send data to the setup-endpoint before the previous transfer is
finished, the device stalls for good. Hence: Small updates require that
I wait until all previous data has been transferred.

Conclusion: Large transfers hurt much less than small ones.

Thomas

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net          http://www.winischhofer.net/
twini AT xfree86 DOT org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB6ljLzydIRAktyUcRAv1yAJ98N4cBV+LlYrrCBZN+mfwVB/uiRgCfTU5z
bzvK/EAu40xTzPekY6kWy8w=
=MCDl
-----END PGP SIGNATURE-----