nanogui: limit the number of GrMoveWindow() calls!
Subject:
Re: [nanogui] limit the number of GrMoveWindow() calls!
From:
Alex Holden ####@####.####
Date:
6 Aug 2002 10:31:34 -0000
Message-Id: <3D4FA236.7020802@linuxhacker.org>
wang wrote:
> Just compare nxterm with mterm,you could find the mterm is more sensitive,
> I have told you that when just compare speed of running a application
> program ,for example ,at both term we type "ls",there is almost no difference between them on speed .but just drag them ,you will find difference,this is the very speed I am interested in .
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.
Mterm actually cheats in that it skips the last step by not bothering to
redraw the window (hence why it goes black when you move it).
The trade off is between the overhead of creating and destroying a
pixmap and reading the entire window contents from the graphic memory to
offscreen memory, and the overhead of requiring the client to redraw the
window contents.
In GrMoveWindow() there's an alternative move method which is equivalent
to the way Mwin does it, but is commented out. I just tried swapping the
two methods and the other way seems faster.
Wang:
Go into nanox/srvfunc.c and find the GrMoveWindow() function. Change the
line that says "if 1" to "if 0" and the line further down that says "if
0" to "if 1". Recompile and try it again. Does that seem faster to you?
>>Well, halve the number of calls isn't exactly what I said, and I don't
>>expect it to make a big difference either.
> Ok, not a half ,use this method ,I can adjust to 2/3,4/5……,but I do not
> think it will prove your opinion .Do you have some other way to implement
> this?
Yes.
When a window first starts getting dragged (ie. you get a button down
event on the title bar), start a 100ms periodic timer and record the
current actual mouse position. Every time you get a mouse position
event, record the new mouse position but don't do the GrMoveWindow().
Every timer event, do a GrMoveWindow() and record the new actual mouse
position if the current recorded position is different from the current
actual position. When the button is released, stop the periodic timer.
The 100ms value is arbitrary, experiment with different values until you
find one that gives the best results.
--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer
