nanogui: Thread: pixmap buffer patch!

Hi,everyone:
 
  In the  accessory is a patch to implement a single
pixmap buffer,the buffer is dynamical,if it isn't be
use for a while ,it can be released ,and if you don't
use GrMoveWindow(),it will never be created .after 
using it ,the improvement on dragging agility is obvious,
and I'm sure it won't waste any memory .
  Any comments is welcome!
　　　　　　　　wang
####@####.####
　　　　　　　　　　2002-08-25

wang wrote:
>   In the  accessory is a patch to implement a single
> pixmap buffer,the buffer is dynamical,if it isn't be
> use for a while ,it can be released ,and if you don't
> use GrMoveWindow(),it will never be created .after 
> using it ,the improvement on dragging agility is obvious,
> and I'm sure it won't waste any memory .
>   Any comments is welcome!

* As I mentioned before, the hardest problem to solve cleanly with this,
and which you don't seem to have attempted to solve, is the problem of
what to do if something draws to the window that you are currently
dragging. You need to either throw away the buffer or draw to both the
buffer and the window (the former is probably easier).
* Please use the generic timer code (GdAddTimer()) rather than doing the
timing yourself.
* There's a memory leak- when someone drags a window and a buffer
already exists for a different window, a pixmap for the new window is
created and the old one is forgotten instead of being destroyed.
* Don't hard code timing values like that, make it a #define in some
central location with a comment explaining what it is.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

: * As I mentioned before, the hardest problem to solve cleanly with this,
: and which you don't seem to have attempted to solve, is the problem of
: what to do if something draws to the window that you are currently
: dragging. You need to either throw away the buffer or draw to both the
: buffer and the window (the former is probably easier).

I have exactly this problem with the multi-threaded
SMPEG using direct client framebuffer access (which 
now works with GR*() locks.)

One solution is a known-named global semaphore, which
clients wanting to draw directly (either through direct
fb or above through shared memory) grab, and nanowm
grabs as well.  Basically, we would require that
the client/nanowm grab the semaphore for the duration
of the draw/move.

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

Regards,

Greg

> 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

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

Actually, we may not need to spinlock.  We could use the
pthread_mutex stuff that's actually in glibc now.  (That's how
I implemented the multi-thread locking...)

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

Good idea, Jordan.  I'll look into this.

Regards,

Greg

> Actually, we may not need to spinlock.  We could use the
> pthread_mutex stuff that's actually in glibc now.  (That's how
> I implemented the multi-thread locking...)

Two problems with that:

First - your millage may vary with the pthreads in glibc - it works OK
on x86, but not as well on other platforms (MIPS comes to mind).  Plus,
on my system the libpthreads.so is 600k - not exactly thin.

Secondly - uclibc doesn't support threading or mutexes right now.  This
is a point that we need to seriously consider, because uclibc +
microwindows is a natural fit, and it puts us well ahead of any other
GUI systems in terms of size.

Now, on the other hand, writing a mutex is time consuming, and difficult
- and it violates the basic open source premise of "don't reinvent the
wheel".  

It is my opinion that having the pthreads dependency is something that
may come back and haunt us.  Thats why I would recommend biting the
bullet and doing it ourselves.

Jordan

On Tue, Aug 27, 2002 at 10:20:18AM -0600, Jordan Crouse wrote:

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

I would discourage this choice.  all locking operations should either
stick with a specific third-party API (pthreads, for instance,) or be
turned into macros / inline functions so whatever is available can be
plugged in.

there is no need to re-invent the wheel when it comes to locking
primitives.  you'll end up duplicating code, and giving yourself
maintenance headaches.

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

if you go the macro / inline route, the default could be empty
operations, which leaves the portability situation no better or worse
than it currently is.

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

pluggable mutex code would make me happy.  RTEMS already provides
locking primitives with optional pthreads API, even.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####

: I would discourage this choice.  all locking operations should either
: stick with a specific third-party API (pthreads, for instance,) or be
: turned into macros / inline functions so whatever is available can be
: plugged in.
: 
: if you go the macro / inline route, the default could be empty
: operations, which leaves the portability situation no better or worse
: than it currently is.
:
This is exactly the way I chose the implementation.  See
src/include/lock.h in CVS for details.  With the default
configuration THREADSAFETY=N, there are no changes.

For RTEMS, you'll need to supply some macros in lock.h
that essentially duplicate the init/lock/unlock functions in your
current wrapper file.

Regards,

Greg