From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <764e15834dcf9dbddc927eade3f6b8c5@vitanuova.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] writing code Date: Fri, 18 Feb 2005 18:52:51 +0000 From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 4d1ebbac-eace-11e9-9e20-41e7f4b1d025 > it should be straightforward to adapt the line drawing algorithm > to put down alpha-blended grey. that would be nice. given that a pixel with alpha notionally represents a partially filled area, might it would make sense to change the interface so that you can specify lengths smaller than integer pixels? if you're using alpha blending, a line that's half a pixel in radius is quite a reasonable thing, for example. > you don't need to accelerate everything, just the common stuff. > the obscured window case you describe is an important one > that should be handled better. i'd love to see that happen. > it's not so much the lack of acceleration as the copying to > backing store and back. i think it has to copy to backing store. i think maybe the underlying problem is that the backing store is in main memory, not video memory. given that video cards these days tend to have lots of memory, maybe it would be possible to allocate some off-screen images in video memory, thus making them accessible to current acceleration routines. i know virtually nothing about vid cards, so this might easily be impossible; just a thought. from a plan 9 point of view, maybe one could make the unused portion of the vid memory another memory pool from which memdraw could choose to allocate? > there have been at least two attempts to do this. the early > brazil kernels maintained state in the Chans and tried to reestablish > them, but my understanding is that the code never really worked > right, and eventually it got taken out. i wrote a user-level file > server for 9P1 that redialed as necessary to keep the connection > running without any help from the kernel. it worked very well > but i never updated it for 9P2000. it's not a big program. i've got an inferno program that does something similar. the problem i have with it is to do with non-idempotent 9p requests. e.g. i send a Tcreate and the server goes down. has the file been created or not? should the intermediate agent resend the request or not after it has connected. as far as i can see, you can't do this in general without some kind of application knowledge. but maybe there's a cunning way of doing it. the first classic example i encountered of this was when i sent a "reboot" message through such a connection. the kernel rebooted immediately (not sending the reply), and as soon as the server came back up again, it resent the request, causing another reboot, and on and on... oh yes, here's another one for the pot: change screen resolution dynamically.