gnome-terminal (actually, vte) uses its solid background as padding at the right and bottom if it's forced to a non-grid size.  Do you see this solid padding in F21?

Do you use transparency?  Official gnome-terminal doesn't support it, it's done by an extra patch shipped by Fedora.

It would help if you could attach screenshots.

Also, can you compile gnome-terminal with debug options, start with
  (from xterm1)
  GNOME_TERMINAL_DEBUG=all /usr/libexec/gnome-terminal-server --app-id foo.bar
  (from xterm2)
  gnome-terminal --app-id foo.bar
and attach the logs (probably with some annotation, e.g. where do you switch to fullscreen)

I have a hunch that maybe gnome-terminal is not asked to use the whole height, only the actual grid-aligned height, and the remainig area is handled by your WM. Just a wild guess, though.

When creating the debug logs, please manually resize the window a couple of times before going half-maximized.  This is for us to see the font size and the fixed additional height, to be able to tell if the maximized height g-t is asked to take up is grid-aligned or not.  Probably this will the deal-breaker whether the bug resides in g-t or the window manager.

This isn't under X11, both bugs are only seen when running under Wayland.

Under X11, the window manager does fully control the size of the window. So if you are suggesting one size, having the window manager change it, and then complying with the final size, this will work.

Under Wayland, the client fully controls the size of its surface; the server merely sends suggestions as to what size it should be. So it is GTK+/VTE/Terminal's responsibility to pad out the size it generates to the full size. The issue with tabs gets a little more tricky and requires more tracking by the client in order to not overflow the screen.

I have not attached the debug output as a Clutter bug causes Mutter to crash every single time I close a window under the Mutter/Wayland session. If you still need it when this is fixed, I can provide it then. Note that you can also get the entire Wayland protocol dump by setting WAYLAND_DEBUG=client; the xdg_shell.configure() events from the server pass the server-requested size, and then you can see the client creating buffers with wl_shm_pool.create_buffer.

Seems you have a much better understanding of the story, at this moment I can't comment anything worthwhile.  I've never seen Wayland, and me using Ubuntu is probably not ideal for trying it out.  I hope ChPe has a much better overview.

What I see under X11 is:

- If a vte widget is asked to have a non-aligned size, it fills the unused part with the terminal's solid background color.

- If gnome-terminal is asked to have a non-aligned size, its embedded vte will also do so (rather than being smaller and leaving pixels in g-t that don't belong to vte -- in fact, the vte widget doesn't seem to have any geometry hints; no clue if it'd even be possible for a Gtk widget).

With these two, I have no clue where the zebra-like peek through bug could sneak in :)

Maybe I totally misunderstand you.  That's why a screenshot could help.  What do you mean by "dirty like zebra"?  Is it strictly speaking broken (showing pixels that can't reasonably be explained), or is it that it's transparent, showing the app underneath or the desktop background, although you'd prefer that area to be taken up by g-t?

Sorry, 'dirty like zebra' is an old/bad inside joke ...

I mean that the window size is mismatching. Under X11, Mutter forces the window size to take the entire vertical span of the screen. Under Wayland, where the client controls the window size, there are two issues:
  - the window does _not_ occupy the whole vertical space, but just rounded down to the nearest character cell - thus there is a gap between the bottom of the terminal and the bottom of the screen
  - when adding a tab bar, the window size grows (off the bottom of the screen) to accommodate this, instead of retaining a constant window size

The last one is more difficult to solve I suspect, but it is at least possible.

(In reply to Daniel Stone from comment #6)
> Sorry, 'dirty like zebra' is an old/bad inside joke ...

Combine that with a non-native English speaker :)

Okay, so basically we need to implement these logics in g-t:
- window dimension should be either a multiple of cell size plus chrome, or exactly the desktop size
- if it's the desktop size, it should be kept so if the chrome size (e.g. 2nd tab opened) or font size changes.

Am I right?

And while we're at it, we should preferably also fix bug 731137 for Wayland.

(In reply to Egmont Koblinger from comment #7)
> Okay, so basically we need to implement these logics in g-t:
> - window dimension should be either a multiple of cell size plus chrome, or
> exactly the desktop size
> - if it's the desktop size, it should be kept so if the chrome size (e.g.
> 2nd tab opened) or font size changes.
> 
> Am I right?

Hmm, I would probably rephrase this to:
  - if in normal state, snap window to multiple of cell size plus chrome
  - if maximised/fullscreen, always preserve requested window size

You get this information from Wayland, and X11 also carries it in the EWMH window hints. It looks like the best way to track this is through the GtkWidget's window-state-event handler.

> And while we're at it, we should preferably also fix bug 731137 for Wayland.

Yes, they seem related.

*** Bug 747943 has been marked as a duplicate of this bug. ***

-> gtk+

See also https://bugzilla.redhat.com/show_bug.cgi?id=1228081

I think this is a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=751368

*** This bug has been marked as a duplicate of bug 751368 ***