Re: Some questions regarding _gdk_window_impl_new() (csw, win32, patch)

[Hans Breuer <hans breuer org>]

At 27.08.2010 22:41, Hans Breuer wrote:
> At 24.08.2010 10:14, Alexander Larsson wrote:
> > On Sat, 2010-08-21 at 14:09 +0200, Hans Breuer wrote:
[...]
> > > - if the information given to _gdk_window_impl_new() is redundant,
> > > as with GDK_WA_VISUAL set and visual given by parameter, which one
> > > has precedence?
> >
> > Use the visual parameter, it is based on GDK_WA_VISUAL if set already.
> So I could assert on it ...
>
> > From attributes the only things used is: colormap, title, wmclass and
> > type_hint.
Unfortunately also wclass is not always set and the backend code was still 
relying on it. Even _gdk_offscreen_window_new() does use wclass without 
check, though that does not matter in this case because the culprit is 
gdk_window_ensure_native().
Maybe some of 
https://bugzilla.gnome.org/review?bug=628049&attachment=168824 should be 
applied?

[...]
> To rephrase my question: where should I start searching for the
> incompatibility introduced with csw? For some reason Dia tries to create
> a pixmap with the visual depth of the GDK_INPUT_ONLY window.
> The fatal attempt to create a pixmap with depth=0 can be overcome by
> setting depth=visual->depth for input-only windows.
> It also can be avoided with the attached patch, but both approached look
> quite wrong. Do you have a better idea?
The bug was the above, an unconditional check on (attributes->wclass == 
GDK_INPUT_OUTPUT) leading to the wrong native window being created.

Something similar is also done in gdkwindow-directfb.c(_gdk_window_impl_new)

Regards,
	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert