#57 Set GtkWindow background color to terminal background color

[Jim Paris]

With my color profile set to a black background, RoxTerm shows a brief flash of white when the terminal window opens, and there are white edges visible briefly while resizing the window larger. This is due to the white background color of the GtkWindow widget (at least with my GTK theme), because it resizes and draws before the VTE widget gets a chance to.

This patch fixes it by having RoxTerm set the toplevel GtkWindow background to the color scheme's background color (if set).

[Tony Houghton]

Thanks. I've just pushed a change based on this patch.

[Tony Houghton]

I think I'm going to have to reject this after all. It makes the background colour also apply to the background of the tab area, which looks quite ugly if it's black and/or translucent. I can't see a way to change the style of that part of the notebook widget, and applying a background to the entire widget would probably defeat the object of applying it to the window.

I tried the existing release in gnome-shell (with compositing) and in "classic" mode (without compositing) and only in Classic could I detect any flicker at all, and I wouldn't have noticed if I hadn't been looking for it. So I think the old behaviour is the lesser of two evils. I don't want to add an option for it, at least not now.

What window manager are you using? Is it a relatively slow PC? roxterm-gtk2 or -gtk3 (although both seem to be about the same to me)? Does gnome-terminal have the same problem for you? It looked as bad as roxterm to me, and I can't see code in it to set the window background colour.

[Anonymous]

I'm not using tabs (my roxterm looks like xterm), so I hadn't noticed
that problem.

I'm using roxterm-gtk3 under XFCE, with openbox. It's a fast PC, but
my total screen resolution is 3968x1280 split across 3 monitors, two
of which are rotated, so screen updates can be a little bit slow
sometimes.

gnome-terminal does exhibit the same problem. I also see it when
moving another window in front of a gnome-terminal, as the uncovered
regions show up white or grey before the vte widget repaints.

Here is a quick video just to demonstrate what I'm seeing:
https://www.youtube.com/watch?v=mymD2B_1OcY

It shows three windows:
Roxterm window in background (319x88 chars, 1920x1157 pixels)
Gnome-terminal on left (about 160x50 chars)
Roxterm window on right (about 160x50 chars)

Resizing gnome-terminal window shows grey background color, resizing
the (patched) roxterm looks good.

[Tony Houghton]

I'm not seeing anything as pronounced as that, but when I tried to copy what you did I got a lot of flicker in the scrollbar - as before, only in "Classic" GNOME, not with compositing. It's probably the vsync that usually comes with compositing which is cleaning it up. Is compositing a realistic option for you? If openbox can't do it I'm pretty sure there's something that can enable compositing with any window manager, but its name escapes me.

[Jim Paris]

I tried with two compositors (xcompmgr and unagi), and it's basically
the same. As I understand it, they're XRender-based and can't do
vsync, and there are no standalone OpenGL compositors that I can use
with OpenBox (https://bbs.archlinux.org/viewtopic.php?pid=1064297#p1064297).

A compositor isn't really the right answer for me anyway; it's just
hiding the problem in the case where the system is fast enough to
fit the two redraws into the same vsync. But I'd still be left with a
graphical glitch that shows up under load.

[Tony Houghton]

Mainly to remind myself:

I've thought of something else I could try: reenable the patch but add an event box with a solid/visible background as the top-level child of the window. I give it a 50/50 chance of working :-/.

[Tony Houghton]

Is this still a problem in version 3? The way vte and roxterm handle the background has changed lately.