Tabbed slow rendering?

[dansbandit]

tried to run tabbed -c vimb -e from the documentation but it is not responsive at all. Tried opening a web page with tabbed and 2 tabs and without tabbed. I'm using the latest git branch for vimb and tabbed. I got some errors below but I don't know if they're related to the issue.

(vimb:5473): Gdk-WARNING **: vimb: Fatal IO error 0 (Success) on X server :0.

(vimb:5563): Gdk-ERROR **: The program 'vimb' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 7215 error_code 3 request_code 18 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

(vimb:5454): Gdk-ERROR **: The program 'vimb' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 3554 error_code 3 request_code 18 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

[fanglingsu]

Can someone else reproduce the issue? You could look in the Xorg log to get more detailed information about the issue. I could imageine, that this might be related to the video driver you use, but it's only a guess.

[michelbehr]

Same problem here, same error.

[fanglingsu]

Does vimb run without such errors if it's started from cli without tabbed? Are there some information in the xorg log?

[semarie]

Daniel,

I have switched from gtk2 to gtk3 for vimb (by compiling with GTK=3), and I have the same problem now. I will investigate this issue, and report elements.

For now:

• the application seems inresponsive at loading, or when scrolling.
• it occurs on a lot of pages (remote [http://] or local [file://]).
• when hanging, if I switch vimb in background (the window is hidden), and go back in foreground, the rendering is actualised immediatly.
• no errors in terminal nor Xorg log file.

It seems to be something like a buffering problem (display is not actualised).

[fanglingsu]

I had some issues with gtk3 and screen update too. As I remember rightI changes the accel method for th intel grafic driver to get rid of it. In my case the scroll percent where not updated on scrolling the page. To update the screen I needed to switch the dwm tag. I'm on another machine so I'll look for the changes I made soon.

[fanglingsu]

Ok, confimed. With GTK3 I can reproduce the issue. So I have this never fixed. I'll try to interprete the debug information written when called like

tabbed -cdn tabbed-vimb -r 2 ./vimb -e '' --gtk-debug=all --gdk-debug=all

It's strange, the GDK-Error does appear only sometimes, and I didn't have luck to get it with gdb.

[semarie]

The refresh seems to occurs when XEMBED_FOCUS_IN and/or XEMBED_WINDOW_ACTIVATE. (trace with GTK_DEBUG=plugsocket in env).

So a mouse out / mouse in permit to "stop the hang" (I don't known how to rephrase this).

[semarie]

I have the same comportement with tabbed -c dwb -e (rendering seems to hang).

[fanglingsu]

I've written a quick and dirty tabbed replacement with gtk sockets to embed vimb. If I run vimb (GTK3) within this, it works well. It seems that GTK3 embed feature does only work together with gtk socket but not with Xlib like used in tabbed.

[fanglingsu]

I found an issue in gnome bugtracker https://bugzilla.gnome.org/show_bug.cgi?id=701613 that sound really similar to our issue. But the gdk_x11_window_set_frame_sync_enabled(..., FALSE) does not change anything for the issue.

[fanglingsu]

If I disable the no scrollbars feature the screen is updated some more so that scrolling via j, k, and CTRL-F, CTRL-D, CTRL-U and CTRL-B are working. But gg does not updated the screen and also scrolling with twodigit counts like 50g does not update the screen. All the key-bindings that are handled by gtk and/or webkit (HOME, END, Page-Up and Page-Down) cause the screen to be update too.

[jasonwryan]

I am seeing this as well: irrespective of how I start vimb in tabbed, or the options I pass to tabbed: it either hangs, or doesn't repaint any motion until you switch tabs.

Can I do anything else to help debug?

[fanglingsu]

I can reproduce this with GTK3 but I'm out of Ideas where to look for the reason. As I can see, this issue is not really realted to vimb. I've written a 50 Lines webkit browser which opens a single page and is embedable and allows to scroll by key press. And also this is affected by the issue. At the time I suggest to built agains GTK2 until we have a running vimb on webkit2/gtk3 which does not show this behaviour. But the webkit2 version is not in a state to do a first commit into a developement branch, there is too much that does not work.

[jasonwryan]

Thanks Daniel: buidling with make GTK=2 is an effective workaround.

[fanglingsu]

Cosed because of long time of inactivity. Hope that this will be fixed with webkit2.

[pando85]

I had to rebuilt it using GTK2 to work properly with tabbed.

[mlopes]

I'm also having this issue, with tabbed vimb doesn't redraw the pages until I switch to other application and back, without tabbed, everything works ok.

Did anyone managed to find an alternative workflow?

[fanglingsu]

@mlopes I had this issue too since the migration to webkit2. I've changed my way of browsing and used vimb without tabbed since several months. But I'm running vimb now within tabbed and it works well, as I can say at this point.

Commit:          3.1.0-12-g9acf271
WebKit compile:  2.20.1
WebKit run:      2.20.1
GTK compile:     3.22.30
GTK run:         3.22.30
libsoup compile: 2.62.1
libsoup run:     2.62.1
Extension dir:   /usr/lib/vimb

Tabbed is at latest version, but I can't see any changes that should have fixed our issue. So I assume that the issue was in gtk and is now fixed.

As I remember the screen was redrawn for me when I scrolled using the cursor keys. But I'm not sure about this.

[mlopes]

I'm installing it via Arch's AUR vimb package. Using vimb 3.1.0, gtk3 3.22.30-1, webkit2gtk 2.20.1-1, libsoup 2.62.1-1. Maybe I should try the vimb-git package. I'll post an update after trying that.

Edit: The issue still happens for me with vimb-git

Commit:          3.1.0-15-gf20cbce
WebKit compile:  2.20.1
WebKit run:      2.20.1
GTK compile:     3.22.30
GTK run:         3.22.30
libsoup compile: 2.62.1
libsoup run:     2.62.1
Extension dir:   /usr/lib/vimb

tabbed version is 0.6-2 should probaby try a newer version and see what happens.

Edit: Still happening for me with tabbed 0.6.35

[fanglingsu]

@mlopes I'll use vimb + tabbed some more time and check other systems too. But I do not have any idea why it works for me now. Might be change compiler flags for compiling tabbed and vimb, changed environment, or sonething else.

[fanglingsu]

Oh, I can reproduce this too. But only in case I opened the webinspector. After that, the screen is not redrawn #420.

[mlopes]

Might be worth mentioning I'm running xmonad (0.13), that may have something to do with it.

[fanglingsu]

I'm running dwm and the issue seems to begin right after opening the webinspector. If I close the webinspector the screen is also not updated anymore.

[svensp]

I might have something that is helpful here. I tracked down a frequently occuring vimb drawing hang in tabbed and it turned out to be within update_urlbar. It happens when gtk_label_set_text(GTK_LABEL(c->statusbar.left), str->str); tries to set a very long uri. The interesting thing is that the actual size that is a problem depends on your tabbed window size(and I assume the font used) which might be why some users are experiencing this and others are not.

I tried using a substring until it worked in for me in full screen, which turned out to be 96 characters. Then tried again using a smaller tabbed window where it hung once again. Setting gtk_label_set_max_width_chars also works, but once again only until the window becomes too small for the number of characters specified.

[fanglingsu]

@svensp Thank you for you investigation! Great work! If I shrinkt the tabbed window the screen is also not redrawn until i switch the tag or focus some other window. As I see there are in fact two window redraw issues.

1. Appears only if the webinspector was opened and keeps there also when the webinspector is closed.
2. When the window title does not fit into tabbed.

Maybe both issues are the same. But I do not have any goof idea how to identify the missing code in vimb or tabbed or gtk to avoid these screen redrawing issues.

[fanglingsu]

As I can se surf seems to be not affected by both of the issues. So I assume that the issue is cause by vimb itself and we can fix the issues.

[svensp]

I'm pretty sure it's a problem with the size renogiation of the box layouts when one element becomes too large to have everything on screen. Some kind of infinite loop between -> item resize -> layout resize -> window resize -> denied -> layout resize -> item resize. Which is broken when refocusing the window triggers tabbed to force the current size on the embedded application disclaimer thought, I have very little experience with gtk, it is probably just a very wild guess

[svensp]

I tried investigating this from the tabbed end of things:

vimb stops responding after an configurerequest event and I believe it starts responding again after a focusin event. focusin includes a call to resize and looking at the code there are only minor differences between resize and the client part of configurerequest.

I tried adding resize(sel, ww, wh - bh); to the end of the client part of configurerequest and vimb runs hang-free both with web inspector and long uris(after removing my workaround of gtk_label_set_max_width_chars of course)

Pretty sure this sends XConfigureWindow twice but since I have no idea about X programming on that level I'd rather not mess with it. I only know vimb works with the extra resize there.

[fanglingsu]

@svensp Thank you for you work. Hope this helps to near down the issue and to find a way to fix it from within vimb.

[svensp]

I don't think this is an issue within vimb.

To test this I added a simple vertical box layout to surf, webkit on top and a long label at the bottom, then ran it within a small tabbed window. The window title changes but it does not render until I mouse into tabbed(causing an infocus event)

surf.c test code:

~ 1308    GtkBox *box = gtk_box_new(GTK_ORIENTATION_VERTICAL, 0);                                                                                      
+ 1309    gtk_box_pack_start(GTK_BOX(box), GTK_WIDGET(c->view), true, true, 0);                                                                        
+ 1310    GtkLabel *label = gtk_label_new("This is a test super long testlabel 123465776435213412341234214321341234213412421342134213412342134132412343
       2143214123421343214132");                                                                                                                       
+ 1311    gtk_box_pack_start(GTK_BOX(box), GTK_WIDGET(c->view), true, true, 0);                                                                        
+ 1312    gtk_box_pack_start(GTK_BOX(box), GTK_WIDGET(label), false, false, 0);                                                                        
+ 1313                                                                                                                                                 
+ 1314    gtk_container_add(GTK_CONTAINER(c->win), GTK_WIDGET(box));                                                                                   
+ 1315    //gtk_container_add(GTK_CONTAINER(c->win), GTK_WIDGET(c->view));                                                                                   

Looking at the names I'd guess after sending a configurerequest gtk stops rendering until it receives an XConfigureEvent. For some reason tabbed only sends XConfigureWindow with an XWindowChanges Object as answer to a configurerequest. resize sends both these events.