Re: SetTransparent gtk3 (#18592)
VZ
@paulcor This is the last issue with 3.1.6 milestone and I'll try to do something (still no idea what exactly) about it next. Do you have any pending changes or ideas about how/what should be changed here by chance?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.
paulcor
The options are either: require SetTransparent() be called before showing, require SetBackgroundStyle(wxBG_STYLE_TRANSPARENT) be called before showing, or force RGBA visual for all TLWs.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
Dan Gudmundsson
Is that "," an 'or' or an 'and' ?
I already call setBackgroundStyle before create and it gives me a transparent white window,
but it should be blue'ish {95,138,255,200}. (with Ubuntu delivered wxW-3.0.4) not tested latest master yet.
I have two use-cases for this:
- Marquee selection (on top of OpenGL window, so don't want to redraw for every mouse move event).
- Moving TLW-tool-windows to attach them to the "main" window, use a transparent window to mark where it will be placed, as is done in AUI.
create_overlay(Parent, ScreenPos)
Flags = ?wxFRAME_TOOL_WINDOW bor ?wxSTAY_ON_TOP bor ?wxFRAME_NO_TASKBAR bor ?wxNO_BORDER,
Overlay = wxFrame:new(),
case {os:type(), {?wxMAJOR_VERSION, ?wxMINOR_VERSION}} of
{{_, linux}, Ver} when Ver >= {3,0} ->
wxFrame:setBackgroundStyle(Overlay, ?wxBG_STYLE_TRANSPARENT)
_ -> ok
end,
true = wxFrame:create(Overlay, Parent, -1, "", [{style, Flags}]),
wxFrame:setBackgroundColour(Overlay, {95,138,255,200}),
Overlay.
overlay_draw(Overlay, Rect, Alpha) ->
catch wxFrame:setTransparent(Overlay, Alpha),
wxFrame:setSize(Overlay, Rect),
wxFrame:show(Overlay).
overlay_hide(Overlay) ->
wxFrame:hide(Overlay).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
I've dome some tests with wxGTK (both Wayland and X11) and there is something really strange going on here: as it is, transparent window in the "shaped" sample (Ctrl-T) does something weird with its lower parts constantly updating even though nothing is changing on the screen underneath them. Also, the display is generally garbled and it's clearly not usable at all. However adding an additional call to SetTransparent() with any non-opaque value fixes it, i.e. with
diff --git a/samples/shaped/shaped.cpp b/samples/shaped/shaped.cpp index 95011739ed..9394812a7d 100644 --- a/samples/shaped/shaped.cpp +++ b/samples/shaped/shaped.cpp @@ -482,7 +482,7 @@ void SeeThroughFrame::Create() wxDEFAULT_FRAME_STYLE | wxFULL_REPAINT_ON_RESIZE | wxSTAY_ON_TOP); - SetBackgroundColour(*wxWHITE); + SetTransparent(254); } // Paints a grid of varying hue and alpha
everything works as expected. So it basically looks like SetBackgroundStyle(wxBG_STYLE_TRANSPARENT) is a prerequisite for using SetTransparent() under GTK.
But under MSW wxBG_STYLE_TRANSPARENT doesn't work at all, i.e. using it just breaks everything (moving, resizing, ...). However SetTransparent() on its own does work. It doesn't compose in the same way, however: all window pixels (including its non-client area BTW) have the alpha value passed to SetTransparent(), whatever OnPaint() does (even if I switch to using wxGraphicsContext in it, because wxDC just ignores alpha completely under MSW, of course). Looking at MSDN, it seems like we could implement support for real composition under MSW, but this would require using DWM API, i.e. writing a lot of (or at least some) new code and I don't think we have time/resources for this.
So for now I'd just settle for SetTransparent() working under all platforms reliably. Ideal would, of course, be to make it "just work", but if we don't want to do this by using RGBA visuals unconditionally (I'm still not aware of any drawbacks of doing this, does anybody know more about it?), then the next best thing I see is to document that SetTransparent() must be called before creating the window to work under all platforms. We would need to modify wxMSW and wxMac to allow doing this there, as currently it only works when the window is already created, but this is doable. And under wxGTK it would need to do what SetBackgroundStyle(wxBG_STYLE_TRANSPARENT) does now before creating the window and call gtk_widget_set_opacity() when it's created.
Should I do this or does anybody see anything better?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
@paulcor I wonder if you could explain me why things don't work for me right now without a SetTransparent() call in wxGTK even though it does absolutely nothing when using Wayland and, if I'm reading GTK code correctly, should also do nothing when using RGBA visual with X11.
I also wonder if we shouldn't be calling gdk_window_set_opaque_region(w, NULL) when using transparent windows with Wayland, as recommended by the comment here?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
paulcor
So, here is what I have found. With the following changes, SetTransparent() works with the minimal sample on both X11 and Wayland:
diff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp index 470e765423..17d644862a 100644 --- a/samples/minimal/minimal.cpp +++ b/samples/minimal/minimal.cpp @@ -122,6 +122,7 @@ bool MyApp::OnInit() // create the main application window MyFrame *frame = new MyFrame("Minimal wxWidgets App"); + frame->SetTransparent(128); // and show it (the frames, unlike simple controls, are not shown when // created initially) diff --git a/src/gtk/toplevel.cpp b/src/gtk/toplevel.cpp index 918e8983c7..6aee5c3a6a 100644 --- a/src/gtk/toplevel.cpp +++ b/src/gtk/toplevel.cpp @@ -1826,6 +1826,8 @@ bool wxTopLevelWindowGTK::SetTransparent(wxByte alpha) return false; #ifdef __WXGTK3__ + GdkScreen* screen = gtk_widget_get_screen(m_widget); + gtk_widget_set_visual(m_widget, gdk_screen_get_rgba_visual(screen)); #if GTK_CHECK_VERSION(3,8,0) if (wx_is_at_least_gtk3(8)) {
And with this change, wxBG_STYLE_TRANSPARENT "works" with the shaped sample on both X11 and Wayland (but there are some undesirable effects, like a menubar or statusbar will have no background, and if combined with SetTransparent() both transparencies will be applied):
diff --git a/src/gtk/window.cpp b/src/gtk/window.cpp index 9a56692b87..633e7afe44 100644 --- a/src/gtk/window.cpp +++ b/src/gtk/window.cpp @@ -2834,6 +2834,7 @@ void wxWindowGTK::PostCreation() if ( m_backgroundStyle == wxBG_STYLE_TRANSPARENT && IsTransparentBackgroundSupported() ) { + gtk_widget_set_app_paintable(m_widget, true); GdkScreen *screen = gtk_widget_get_screen (m_widget); #ifdef __WXGTK3__ gtk_widget_set_visual(m_widget, gdk_screen_get_rgba_visual(screen));
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
Wow, the first change seems ideal to me, thanks! I didn't realize we could set the visual later (mostly due to the comment in PostCreation() just before the second diff saying that it must be done a.s.a.p.) but if we can, this makes SetTransparent() work in the same way under all platforms, so all that remains to do is to change the shaped sample to use it to show something actually working.
The second change is a nice bonus and I think we could make it possible to optionally switch background style to transparent in the sample, so that things would still work by default under MSW but could also show working per-pixel transparency under GTK and Mac (where, BTW, everything just works great already, for once).
Thanks again!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
paulcor
I didn't realize we could set the visual later
Well, it has to be done before the TLW is realized (i.e. shown). I just showed a minimal change for SetTransparent(), it should have some sort of debug message if it's called after realizing.
The second change is a nice bonus
I'm concerned about the large change in behavior this would cause. As stated in the initial comment of this issue, wxBG_STYLE_TRANSPARENT is currently required for SetTransparent() to work with GTK3. If we make wxBG_STYLE_TRANSPARENT "work", it will likely break anyone who is currently using it to get SetTransparent() to work.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
I didn't realize we could set the visual later
Well, it has to be done before the TLW is realized (i.e. shown). I just showed a minimal change for
SetTransparent(), it should have some sort of debug message if it's called after realizing.
Yes, I think wxLogDebug() should be enough, i.e. it's not worth an assert failure. Or is it?
The second change is a nice bonus
I'm concerned about the large change in behavior this would cause. As stated in the initial comment of this issue,
wxBG_STYLE_TRANSPARENTis currently required forSetTransparent()to work with GTK3. If we makewxBG_STYLE_TRANSPARENT"work", it will likely break anyone who is currently using it to getSetTransparent()to work.
I don't know since when did using wxBG_STYLE_TRANSPARENT become required for SetTransparent() to work, I distinctly remember the latter working without the former, but this must have been several years ago. Considering the weird thing it does if it's used on its own right now (I still have no real explanation to what I'm seeing when using it), I think we can afford to make this change before 3.2.0.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
SetTransparent() does work now and the sample shows it, so I think this can be considered as closed.
Thanks again Paul!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
VZ
Closed #18592.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.