nanogui: Thread: Why does microwindow (API Win32) display child window first ?

Hello,

I presently work on transparency in microwindow through the Win32 API.
I do not understand the redrawing strategy of microwindow.
When redrawing a window, Microwindow redraw children windows BEFORE mother
window.

So i have 2 remarks :
- why not drawing mother and then childrens in Z order which avoid the
complex mechanism of clipping.
- With the current strategy, we are not able to manage transparency quite
being 100% compliant with the Win32 API.


If i want to force re-drawing in Z order, how could i do that ?

Thanks for your job.

> I presently work on transparency in microwindow through the Win32 API.
> I do not understand the redrawing strategy of microwindow.
> When redrawing a window, Microwindow redraw children windows BEFORE mother
> window.

I think that Windows uses the same strategy, so that child
windows appear before the background windows.  Due
to other considerations, we still have to use the clipping
mechanism, since the child windows need to be contained
in their parent.




> - With the current strategy, we are not able to manage transparency quite
> being 100% compliant with the Win32 API.

I'd like to hear more about this.



> If i want to force re-drawing in Z order, how could i do that ?

One of the first functions in mwin/winuser.c traverses the window
list, you can rewrite that.

Regards,

Greg

> > I presently work on transparency in microwindow through the Win32
> API.
> > I do not understand the redrawing strategy of microwindow.
> > When redrawing a window, Microwindow redraw children windows BEFORE
> mother
> > window.
> 
> I think that Windows uses the same strategy, so that child
> windows appear before the background windows.  Due
> to other considerations, we still have to use the clipping
> mechanism, since the child windows need to be contained
> in their parent.
> 
> 

No, it is not right Window redraw mother BEFORE children. I have done some 
tests under Win2000 and the redrawing strategy is systematically mother BEFORE 
child. Furthermore if i ask a mother redrawing, it automatically send WM_PAINT 
to the children.

> 
> 
> > - With the current strategy, we are not able to manage transparency
> quite
> > being 100% compliant with the Win32 API.
> 
> I'd like to hear more about this.
> 

Under window, it is easy to manage transparency, because when a window receive 
the WM_PAINT it can assume that the complete under window had already been 
redraw.
Under MicroWindow the repaint order is not predictable, it depend on the 
chained list order. So when a window receive the WM_PAINT it can't assume that 
the under window had already been redraw. In fact, cause of the clipping we 
allways get a black area. With that strategy we can't manage transparency in 
the same way has Window.

I work on modifications to be Window compliant, it need 2 kinds :
1st -  we must not clip children sytematically, WS_CLIPCHILD and WS_CLIPSIBLING 
must be avoid in CreateWindowEx. But i don't fell all the sides effect of it.
2nd - i think of a solution to redraw window from mother to children, not 
following the chaine list of the window, but following the tree built by 
mother, children and sibling window.

I face some problems, because the WM_PAINT message is not manage in the same 
way than other messages.

I will send a patch of my modifications as soon as possible.

Thanks for all

TSI Alpha3i's Team

Damien