On Tue, Apr 23, 2002 at 02:18:33AM +0200, Marcus Brinkmann wrote: > There are probably more points that I forgot now,
Yeah, I have two more. When having character data and attribute data not interleaved, you have an ugly race condition that can lead to an update of the attributes but not the text or the other way round. So for a small amount of time the wrong attributes might be used for a text (unless we either make it the convention that notification messages for text imply change of the attributes, or we span the whole region between the text and the attribute and declare it as changed, which is inacceptable). OTOH, if the attributes and text are interleaved, you can not update just the text and leave the attributes intact without update (so you might or might not lose some performance this way). There is another race like this with asynchronous update messages. Consider that the text ABCDE is written to the screen, and then the text 12345 is written just over that. While the display driver processes the first notification, it reads out the mmap'ed buffer and might read ABC45, if the change in the virtual screen is performed after it has read the C. Of course, with the next notification message, it will process this region again, and will write 12345. Ok, I am scrutinizing the standard issues for asynchronous screen updates. Maybe the times that such incorrect renderings occure are too small to even worry about it. However, I think it is good to know what we are talking about. Some of this could be fixed by synchronizing the virtual screen with the display driver, but this is probably inacceptable performance-wise. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
