nanogui: Thread: Re: about Windows redraw

Hello:

       I find that a new windows always redraw when it 's created the first time . 
    I notice that when a new windows is created ,it always receives the event GR_EVENT_TYPE_UPDATE two times. I think that maybe this is the reason that the windows always refurbish two times . Is it a bug ?

       How can I fix it ? Thanks in advance !

                          xgzhang

    

Hello:

       I find that a new windows always redraw when it 's created the first time . 
    I notice that when a new windows is created ,it always receives the event GR_EVENT_TYPE_UPDATE two times. I think that maybe this is the reason that the windows always refurbish two times . Is it a bug ?

       How can I fix it ? Thanks in advance !

                          xgzhang

    

xgzhang！

	If you are using nanowm ,you will see clearly
that the window is redraw for the second time when 
be creted. first for the event GR_UPDATE_MAP,and 
later for the event GR_EVENT_TYPE_EXPOSURE,the first 
event is responded by the child window,and trigger
the EXPOSURE event ,nanomw get the event ,and draw 
the container, because the original window is children
of the container ,so it should be redraw for the 
second time.
    
   If we still keep window manager out of server ,
this problem will be not easy to deal with.

======= 1999-07-29 09:58:00 =======

>Hello:
>
>       I find that a new windows always redraw when it 's created the first time . 
>    I notice that when a new windows is created ,it always receives the event GR_EVENT_TYPE_UPDATE two times. I think that maybe this is the reason that the windows always refurbish two times . Is it a bug ?
>
>       How can I fix it ? Thanks in advance !
>
>                          xgzhang
>
>    

= = = = = = = = = = = = = = = = = = = =
			

　　　　　　　　致
礼！
 
				 
　　　　　　　　wang
####@####.####
　　　　　　　　　　2002-07-15

wang wrote:
> =09If you are using nanowm ,you will see clearly
> that the window is redraw for the second time when 
> be creted. first for the event GR_UPDATE_MAP,and 
> later for the event GR_EVENT_TYPE_EXPOSURE,the first 
> event is responded by the child window,and trigger
> the EXPOSURE event ,nanomw get the event ,and draw 
> the container, because the original window is children
> of the container ,so it should be redraw for the 
> second time.

There is a (slightly ugly but working) solution for this in my CVS tree.
You can get it from here:
http://www.linuxhacker.org/pub/cvs-snapshots/microwin-aph/

The way it works is that the client has a bit of code which looks like this:

GR_COORD y = 0, x = 0;

if(GrGetWindowProperty(GR_ROOT_WINDOW_ID, "WINDOW_MANAGER", &prop)) {
   free(prop);
   x = GR_OFF_SCREEN;
}

The window manager creates the WINDOW_MANAGER property when it starts up.

x and y x are then used as the position of the window when it is
created. If there is no window manager running, it will be placed at
0,0. If the window manager is running, it will be placed off the screen.
The window manager then reparents the window and moves it to somewhere
on the screen. Because the location of the first mapping was not
visible, you don't see the window get drawn twice.

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

Alex！

	This is a way to avoid seeing the client window
be drawn two times,but this only solve the sight
problem,in fact ,the window still be drawn for two
times.
    Every time if we want to run a graphic program 
base on nano-X ,we always let nanowm run too.so we 
can set the window anywhere ,it's so convenient .
window manager have the equal importance as the graphic
server,but everyone can find that when we drag  a 
window base on nano-X ,it's slower than the we drag
window which base on mwin,the reason is very obvious--we 
have travelled  an extra road ,in mwin the dragging 
be dealt with by itself,no extra communication ,no 
extra program,but in nano it's not.
    Some events which should be dealt with by wm,
and this events don't have impact  on the client.
and we can call most of them globle event ,so putting 
the serve fuction out of graphic server is very 
out of place.
    To let window dragging and window management 
more quickly,I suggest we should put window management
in the graphic server.when we creat a window with 
Grnewwindow(),it shoud create a containner too.every
window should have a containner as its parent,make it 
to be the basic element of a window ,so we can draw 
the window for only one time .and we alse should put 
some event serve fuction inside graphic server,such 
as when we drag the window ,when we make certain window
uncovered.
    anybady have some suggestion ,please let me know.

    

======= 2002-07-15 10:31:00 =======

>wang wrote:
>> =09If you are using nanowm ,you will see clearly
>> that the window is redraw for the second time when 
>> be creted. first for the event GR_UPDATE_MAP,and 
>> later for the event GR_EVENT_TYPE_EXPOSURE,the first 
>> event is responded by the child window,and trigger
>> the EXPOSURE event ,nanomw get the event ,and draw 
>> the container, because the original window is children
>> of the container ,so it should be redraw for the 
>> second time.
>
>There is a (slightly ugly but working) solution for this in my CVS tree.
>You can get it from here:
>http://www.linuxhacker.org/pub/cvs-snapshots/microwin-aph/
>
>The way it works is that the client has a bit of code which looks like this:
>
>GR_COORD y = 0, x = 0;
>
>if(GrGetWindowProperty(GR_ROOT_WINDOW_ID, "WINDOW_MANAGER", &prop)) {
>   free(prop);
>   x = GR_OFF_SCREEN;
>}
>
>The window manager creates the WINDOW_MANAGER property when it starts up.
>
>x and y x are then used as the position of the window when it is
>created. If there is no window manager running, it will be placed at
>0,0. If the window manager is running, it will be placed off the screen.
>The window manager then reparents the window and moves it to somewhere
>on the screen. Because the location of the first mapping was not
>visible, you don't see the window get drawn twice.
>
>-- 
>------------ Alex Holden - http://www.linuxhacker.org ------------
>If it doesn't work, you're not hitting it with a big enough hammer

= = = = = = = = = = = = = = = = = = = =
			

　　　　　　　　wang
####@####.####
　　　　　　　　　　2002-07-16

wang wrote:
> 	This is a way to avoid seeing the client window
> be drawn two times,but this only solve the sight
> problem,in fact ,the window still be drawn for two
> times.

Are you sure? That shouldn't happen because the window is not visible
when it is first mapped. I just tried it with nxterm and it only gets
one exposure event when it maps. If it is generating an exposure event
for you when the window is off screen that should be fixed.

>     Every time if we want to run a graphic program 
> base on nano-X ,we always let nanowm run too.so we 
> can set the window anywhere ,it's so convenient .
> window manager have the equal importance as the graphic
> server,but everyone can find that when we drag  a 
> window base on nano-X ,it's slower than the we drag
> window which base on mwin,the reason is very obvious--we 
> have travelled  an extra road ,in mwin the dragging 
> be dealt with by itself,no extra communication ,no 
> extra program,but in nano it's not.

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.

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
edge. The way X does it is that it sends a group of expose events
(remember if you move a shaped window over another window it could
generate a lot more than two exposed rectangles) with each event having
a count of how many events remain in the group. If your application
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.

The other thing you could do if you think solid window dragging is slow
is to implement outline window dragging.

>     Some events which should be dealt with by wm,
> and this events don't have impact  on the client.
> and we can call most of them globle event ,so putting 
> the serve fuction out of graphic server is very 
> out of place.

There are many advantages to having the window manager as a seperate
process. It might seem "out of place" if you're not used to X, but the
people who designed it did have good reasons for not putting window
management in the server.

>     To let window dragging and window management 
> more quickly,I suggest we should put window management
> in the graphic server.when we creat a window with

If you want to implement an in-server window manager, go ahead (just
make sure it's a compile time option). However I don't think it will
significantly increase the speed of window drags. The one big advantage
it would have is that it would be possible to have window management in
"app linked into server mode".

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

>> =09If you are using nanowm ,you will see clearly
>> that the window is redraw for the second time when
>> be creted. first for the event GR_UPDATE_MAP,and
>> later for the event GR_EVENT_TYPE_EXPOSURE,the first
>> event is responded by the child window,and trigger
>> the EXPOSURE event ,nanomw get the event ,and draw
>> the container, because the original window is children
>> of the container ,so it should be redraw for the
>> second time.
>
>There is a (slightly ugly but working) solution for this in my CVS tree.
>>
>if(GrGetWindowProperty(GR_ROOT_WINDOW_ID, "WINDOW_MANAGER", &prop)) {
>   free(prop);
>   x = GR_OFF_SCREEN;
>}
>
>The window manager creates the WINDOW_MANAGER property when it starts up.
>

The solution to all of this, without using Alex's
fix which requires user application modifications,
nor adding the window manager into the server, or
requiring container windows as suggested by Wang,
is the following:  implement the X11-style
substructure-redirect operation.  The way it
works it this:

1. Add a new event mask, GR_EVENT_MASK_CHILD_REDIRECT.
2. The first program that requests this event mask,
which will only be used on the root window, will
get special treatment from the nano-X server.  This
program will always be the window manager.  Nano-X
will record the process id for the current application
requesting this mask, and only honor one application
at a time.
3. When a window requests a map or unmap operation,
the server will check whether it's parent (in this,
case, the root window) has the CHILD_REDIRECT mask
set.  If so, the operation WILL NOT be performed
for the requesting application, and instead, the
entire operation repacked as a new event type,
EVENT_TYPE_REDIRECT, and sent to the application
which set the mask bit, which is the window manager.
The window manager will then implement policy
by deciding to 1) ignore 2) modify 3) complete
the request on the original application's behalf.
4. In the case of a map event, the window manager
won't execute the child map request until it has
created a new window frame and reparented the child.
This will result in the child window being painted
exactly once.

The CHILD_REDIRECT event mechanism will work
for the following operations: map, unmap,
resize, move, lower, raise and setborderwidth.

Regards,

Greg







This is a way to avoid seeing the client window
be drawn two times,but this only solve the sight
problem,in fact ,the window still be drawn for two
times.
    Every time if we want to run a graphic program
base on nano-X ,we always let nanowm run too.so we
can set the window anywhere ,it's so convenient .
window manager have the equal importance as the graphic
server,but everyone can find that when we drag  a
window base on nano-X ,it's slower than the we drag
window which base on mwin,the reason is very obvious--we
have travelled  an extra road ,in mwin the dragging
be dealt with by itself,no extra communication ,no
extra program,but in nano it's not.
    Some events which should be dealt with by wm,
and this events don't have impact  on the client.
and we can call most of them globle event ,so putting
the serve fuction out of graphic server is very
out of place.
    To let window dragging and window management
more quickly,I suggest we should put window management
in the graphic server.when we creat a window with
Grnewwindow(),it shoud create a containner too.every
window should have a containner as its parent,make it
to be the basic element of a window ,so we can draw
the window for only one time .and we alse should put
some event serve fuction inside graphic server,such
as when we drag the window ,when we make certain window
uncovered.
    anybady have some suggestion ,please let me know.



======= 2002-07-15 10:31:00 =======

>>x and y x are then used as the position of the window when it is
>created. If there is no window manager running, it will be placed at
>0,0. If the window manager is running, it will be placed off the screen.
>The window manager then reparents the window and moves it to somewhere
>on the screen. Because the location of the first mapping was not
>visible, you don't see the window get drawn twice.
>
>--
>------------ Alex Holden - http://www.linuxhacker.org ------------
>If it doesn't work, you're not hitting it with a big enough hammer

= = = = = = = = = = = = = = = = = = = =


　　　　　　　　wang
####@####.####
　　　　　　　　　　2002-07-16





---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####

>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

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

I think it would be a nice addition to have the capability
of having the window manager compiled in to the nano-X
server.  This doesn't mean that now the server alone 
defines policy, because with an appropriate API definition,
any window manager could be linked with the server.

I will think about this more as I implement the 
substructure-redirect mechanism that I spoke of in
the last email.

In the mean time, I am working hard to get out the
next release of Microwindows that includes many additions
and contributions.  I expect to check in much of the code
into CVS very shortly.

Regards,

Greg

: If you are using nanowm ,you will see clearly
that the window is redraw for the second time when 
be creted. first for the event GR_UPDATE_MAP,and 
later for the event GR_EVENT_TYPE_EXPOSURE,the first 
event is responded by the child window,and trigger
the EXPOSURE event ,nanomw get the event ,and draw 
the container, because the original window is children
of the container ,so it should be redraw for the 
second time.

This is correct.  However, the proper fix for
this is to re-design the way that the window
manager receives notification about windows
mapping on the root window for the first time.

My plan is implement an X11-style solution, where
the original map from the application is not
executed, and instead a CHILD_REDIRECT event
is sent to the window manager.  The window manager
then creates the container window, reparents
the application window to it, and then maps
the application window on behalf of the application.
This would result in only a single expose/update event.

Regards,

Greg