Subject:
Re: Re: [nanogui] Fw: about Windows redraw
From:
"wang" ####@####.####
Date:
17 Jul 2002 05:12:53 -0000
Message-Id:
>I'm not so sure it is "very obvious". Have you done profiling which
>proves the inter-process communication overhead is really what is making
>window dragging slow for you? One thing which I think could help is to
>modify nanowm so that instead of synchronously moving the dragged window
>every time it gets a mouse event, it instead keeps track of the movement
>and asynchronously moves the window (if its position has changed) every
>(say) tenth of a second. That would limit the rate at which
>GrMoveWindow() was called (and the resulting redrawing of everything
>under the moved window), increasing efficiency and responsiveness.
Inter-process communication overhead is one reason slow down the
speed ,but most time is wasted during process scheduling.Just let's
have a look at the procedure when we drag a window:first the graphic
server is scheduled ,detech the motion of mouse,generate a event add
to the queue ,the wait for wm be scheduled to deal with the event(we
are not sure when it will be scheduled,so time wasted),fanally it the
turn to wm ,it get the event ,and want move the window ,so it send a
event to server to request to move window,the wait again ,wait the
server to be scheduled(nobaby know how long it will take) ,and deal
with the request.the we see the window be move.unless you have a very
fast processor ,otherwise you will find the speed for such a frequent
operation is too slow.
>There is another reason that dragging a window over another window is
>slower than it should be by the way- the method of reporting exposures
>we currently have in Nano-X is rather inefficient. When you move a
>window a small distance, an exposure event for the area under where the
>window moved from is generated encompassing the entire rectangular area,
>when it really ought to somehow report just two rectangles along the
>(remember if you move a shaped window over another window it could
>generate a lot more than two exposed rectangles) with each event having
>isn't intelligent enough to redraw each rectangle seperately, then you
>just redraw the whole window whenever you see an event with a count of
>0. We could either copy this method, or I think a nicer way to do it
>would be to keep the current Exposure event as it is for old/dumb
>applications and add a new event, which only applications intelligent
>enough to make use of it would select for, that supplies an exposure
>rectangle list to the client in a single event.
Don't say x ,I have nerver given a pride to the speed of x, linux
is so effient and high speed ,why when using x ,all things changed,
unendurable slow speed boring most of us ,and this one reason why I
turn to microwindows,there are two reason for the low speed:
1.Shouldn't put window manager outside graphic server,besides easy to
maintain and modify ,I can't find any other advantage for this.treat
such a frequently used server(I'm willing to say so) just as a common
application,I don't think this is good architecture.
2.Shouldn't treat the graphic server the same as a common application
process,but this can be forgived ,because at a server machine ,graphic
isn't so important.just have a think of such an important server only
can have the same run priority when being scheduled.who will think it
with high speed.
All of these is the drawback of x ,when we create new graphic system,
we should avoid these problem.just have a think of how we deal with cursor
redraw.you will find the enhanced agility when move cursor.why ?because
it be deal with in server,doesn't waste any time.
Uper is my opinion.even more I want get criticism from anyboby .
so we can make the brand-new system faster and more stable,which is
my final aim.
Any suggestion is welcome!
wang
####@####.####
2002-07-17
