nanogui: limit the number of GrMoveWindow() calls!
Subject:
Re: [nanogui] limit the number of GrMoveWindow() calls!
From:
"wang" ####@####.####
Date:
6 Aug 2002 11:32:59 -0000
Message-Id:
>You're right, mterm does seem surprisingly fast, although also broken in
>that the window contents get lost when it's moved.
>
>I just had a look at it, and it seems to be to do with the way
>GrMoveWindow() is implemented in Nano-X vs the way MoveWindow() is
>implemented in mwin.
>
>Nano-X basically does this:
>Create a new pixmap the size of the window.
>Copy the contents of the window to the pixmap.
>Copy the contents of the pixmap to the new location.
>Destroy the pixmap.
>Generate any relevant exposure events.
>
>Mwin basically does this:
>Hide the window.
>Show the window in the new position.
>Ask the client to redraw the window contents.
Yes, alex when I use the new code and drag nxterm ,it have a
faster speed ,but when you open a viewml window and drag it ,
you will find it still very slow .why ? because the radraw of
nxterm is very easy and fast but the redraw of viewml si very
slow,so in fact the method is not in point for any window.so I'm
still willing to chose the first method.
But your suggestion take me a good idea, you know every time
when we call Grmovewindow() we should "creat ,copy,copy,destroy,expose",
and when we are dragging it will call Grmovewindow() many many times,
so why don't we bypass the first "creat,copy "and "destroy",just
at first time we call Grmovewindow we do "creat,copy",and keep
it in memory till the button be released,so at sequent call we
just need to do "copy,expose",this should even faster then the
method we implement in mwin.
wang
####@####.####
2002-08-06