Re: [9fans] writing code

[rog@vitanuova.com]

> 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.