nanogui: pixmap buffer patch!
Subject:
Re: [nanogui] Re: pixmap buffer patch!
From:
Jordan Crouse ####@####.####
Date:
27 Aug 2002 16:26:01 -0000
Message-Id: <1030465218.23244.393.camel@cosmic>
> An issue here is which type semaphore to use, I don't
> want to code it as a Gr*() call, since that would
> involve a client->server->client return trip, and defeat
> the purpose of speed for mpeg displays...
This is what you would need:
You would first need a Gr*() call to set up the shared memory, call it
GrInitMutex(), for example. This would be called for all programs that
want to control access to the shared framebuffer. This would be a call
to the server, which is OK, because it will be called in the beginning,
when speed isn't an issue.
You could then call GrGetMutex() and GrReleaseMutex() to control access
to the frame buffer region. These calls would only be in the client
code so you wouldn't need to worry about making a socket call.
Then each process would call GrDestroyMutex() before exiting.
The shared memory would be controlled by the server - created when the
first process calls GrInitMutex() and released when the last process is
closed. That way the shared memory is only around when it is needed
(which isn't often).
Now, the bad news - the semaphore adds another couple levels of
complexity to the issue, and in order to do it correctly, we will need
to include processor specific assembly language to handle the atomic
read/write operations. This is assuming, of course, that we choose not
to use an 3rd party library. So in order to increase our performance
and control over the shared framebuffer, we are going to have to take a
slight hit in our portability, at least in the near term (until we get a
reasonable library with all of the needed assembly for our most popular
processors).
Having said all this, I vote that we go ahead and add the code. Having
a good internal semaphore system would be useful both now, and in the
future (and it would really make the RTOS guys happy).
Jordan
