lanoxx / tilda

A Gtk based drop down terminal for Linux and Unix
GNU General Public License v2.0
1.27k stars 162 forks source link

Vertical tearing during scrolling #386

Closed bodqhrohro closed 5 years ago

bodqhrohro commented 5 years ago

It happens occasionally, mostly under high system load. Always in the same place. mpv-shot0001

tilda_tearing1

Distro: Debian 10 WM: compiz-reloaded 0.8.17 Tilda: 1.5~alpha libvte: 0.42.1

bodqhrohro commented 5 years ago

Huh, when looking at the screencast, I also noticed that the cursor changed to hand at this moment

bodqhrohro commented 5 years ago

If important, config:

tilda_config_version="0.9.6"
# command=""
font="Ubuntu Mono 14"
key="<Super>space"
addtab_key="<Primary><Shift>t"
fullscreen_key="F11"
toggle_transparency_key="F12"
toggle_searchbar_key="<Shift><Control>f"
closetab_key="<Shift><Control>w"
nexttab_key="<Control>Page_Down"
prevtab_key="<Control>Page_Up"
movetableft_key="<Shift><Control>Page_Up"
movetabright_key="<Shift><Control>Page_Down"
gototab_1_key="<Alt>1"
gototab_2_key="<Alt>2"
gototab_3_key="<Alt>3"
gototab_4_key="<Alt>4"
gototab_5_key="<Alt>5"
gototab_6_key="<Alt>6"
gototab_7_key="<Alt>7"
gototab_8_key="<Alt>8"
gototab_9_key="<Alt>9"
gototab_10_key="<Alt>0"
copy_key="<Shift><Control>c"
paste_key="<Shift><Control>v"
quit_key="<Shift><Control>q"
title="  "
background_color="white"
# working_dir=""
web_browser="x-www-browser"
increase_font_size_key="<Control>equal"
decrease_font_size_key="<Control>minus"
normalize_font_size_key="<Control>0"
# show_on_monitor=""
word_chars="-A-Za-z0-9,./?%&#:_"
lines=1000
max_width=1366
max_height=384
min_width=1
min_height=1
x_pos=0
y_pos=25
tab_pos=0
expand_tabs=false
show_single_tab=false
backspace_key=0
delete_key=1
d_set_title=3
command_exit=2
scheme=0
slide_sleep_usec=15000
animation_orientation=0
timer_resolution=200
auto_hide_time=2000
on_last_terminal_exit=0
prompt_on_exit=false
palette_scheme=0
non_focus_pull_up_behaviour=0
cursor_shape=0
title_max_length=25
palette = {11822, 13364, 13878, 52428, 0, 0, 20046, 39578, 1542, 50372, 41120, 0, 13364, 25957, 42148, 30069, 20560, 31611, 1542, 38944, 39578, 54227, 55255, 53199, 21845, 22359, 21331, 61423, 10537, 10537, 35466, 58082, 13364, 64764, 59881, 20303, 29298, 40863, 53199, 44461, 32639, 43176, 13364, 58082, 58082, 61166, 61166, 60652}
scrollbar_pos=1
back_red=0
back_green=0
back_blue=65535
text_red=65535
text_green=65535
text_blue=0
cursor_red=65535
cursor_green=0
cursor_blue=0
scroll_history_infinite=false
scroll_on_output=true
notebook_border=false
scrollbar=false
grab_focus=true
above=true
notaskbar=true
bold=true
blinks=true
scroll_on_key=true
bell=true
run_command=false
pinned=true
animation=false
hidden=false
set_as_desktop=false
centered_horizontally=false
centered_vertically=false
enable_transparency=false
auto_hide_on_focus_lost=false
auto_hide_on_mouse_leave=false
title_behaviour=2
inherit_working_dir=true
command_login_shell=false
start_fullscreen=false
confirm_close_tab=false
back_alpha=52415
show_title_tooltip=false
# image=""
# show_on_monitor_number=0
# transparency=0
# title_max_length_flag=false
# antialias=false
# double_buffer=false
# scroll_background=false
# use_image=false
egmontkob commented 5 years ago

I get such behavior in gnome-terminal extremely rarely (maybe once a year, or so), and also get something similar in Firefox occasionally.

The scrollbar's handle is also split in half, so it's probably a bug in some common underlying component, like GTK+, X11, window manager, compositor, video card driver... I find it unlikely to be in VTE or Tilda. Notice that the artifact's boundary aligns with your browser's edge, excluding the window border; not only at the problem over your blue terminal, but also at the glitch over the scrollbar handle. Next time such behavior occurs you could move/resize your browser to see if the glitch line follows this, I expect so.

I also cannot exclude the possibility of an overlay transparent window being there, perhaps a leftover from a DRI video player, which somehow mangles its contents or updates to the underlying window's contents with a delay; perhaps (but this is a weak guess) after a crashed video player in the browser.

I have no idea about the mouse pointer; would be interesting to see if there's a link underneath in your browser, visiting that page seems to confirm it. If it's the case, it might make the compositor a bit more suspicious. Which browser is that, by the way?

Are you sure about your VTE version? What does echo $VTE_VERSION say? You scroll by partial text lines, this feature was implemented in 0.44; version 0.42 could only scroll by entire text rows. (It's probably irrelevant though.)

bodqhrohro commented 5 years ago

@egmontkob yes, your observations are right: the shape of the tearing area strictly corresponds to the browser viewport. No matter how deep the browser window is: such glitch happens to any foremost windows, regardless of toolkit; I noticed it in Tilda first just because this is the only app where I do much of smooth scrolling.

So this looks like an issue with the way LuaKit embeds WebKit and its implementation in Compiz: sometimes the layers are composited wrongly. Still not sure on what side exactly, going to check with other WebKit-based browser first. But definitely not at Tilda side.