GNOME Bugzilla – Bug 516869
vte displays nothing on GTK+/DirectFB
Last modified: 2008-10-07 17:06:04 UTC
Please describe the problem: vte is not working on GTK+/DirectFB. I spent quite a lot of time trying to figure out what was actually preventing it to display anything. I have tracked this all way down to the way GTK+/DirectFB currently handles gdk_window_process_all_updates(). It seems that it does actually nothing except during the idle loop. This behaviour conflicts with vte's chain of work and make it totally unusuable. When using VTE_DEBUG_FLAGS=work on the GTK+/X11 port, the "vte" apps show the following pattern: *+{-+=}.[.(?!?!?!)-+=][].........<.(?!?!?!)>{-+=}[]?!+= Whereas on the GTK+/DirectFB port, one gets: *{-}+*.**+[.()-]+*[-]+*[-]+*[-]+*[-]+*[-]+*[-]+*[-]+*[-]+*..[.()-]+* etc. So vte_terminal_paint() is never called, as the vte_terminal_expose() never gets called while "in_update_timeout" is set to TRUE, thus resulting in an empty terminal. Steps to reproduce: Either build vte against a GTK+/DirectFB port and start the "vte" app or the same behaviour can be optained on the GTK+/X11 port by commenting the calls to gdk_window_process_all_updates() in vte.c:update_repeat_timeout and vte.c:update_timeout and starting "vte". Actual results: Nothing is displayed on the widget. Expected results: Characters should be displayed on the widget. Does this happen every time? Yes. Other information: I can think and have fully tested several workarounds for this issue, but none of them feels completely right to me, and I am totally unknowledgable about vte's codebase. So I really wonder what would be the right thing to do to fix this issue. Is the bug actually in the way of handling gdk_window_process_all_updates in the GTK+/DirectFB port?
Which version? Sounds like something we recently fixed: 2007-12-21 Chris Wilson <chris@chris-wilson.co.uk> Bug 503164 – Drawing problems for VTE with gtk+-quartz * src/vte.c (vte_terminal_realize): Continuing the saga, remove the fiddling with visibility state during realize. 2007-12-17 Chris Wilson <chris@chris-wilson.co.uk> Bug 503164 – Drawing problems for VTE with gtk+-quartz * src/vte.c (vte_terminal_init): GdkQuartz does not generate GdkVisibilityNotify events and so the terminal was never marked as unobscured, causing all redraws to be discarded. Resolve this by initially setting the terminal to be unobscured. The fixes are 0.16.12
The version tested was 0.16.12, currently in Debian unstable.
Originally the changes made in Bug 503164 seemed to fix my problem. I hadn't used Gtk+Quartz in a while (and even reinstalled on a new harddrive) and now I am seeing the exact same result as Jeremy. My VTE_DEBUG_FLAGS=work output looks identical to his and is similar to what I was seeing before, except I do get the expose event now. Still no drawing of text. I am however able to type 'ls<enter>' (even though it doesn't show up) and I can see the scroll bar update and see the debug information concerning the insertion of text into window.
Created attachment 110582 [details] [review] Replace gdk_window_process_all_updates() by specific calls to gdk_window_process_updates(). Patch of the current SVN version.
At least one issue for DirectFB support comes from the its implementation of gdk_window_process_all_updates(). Even if there is probably a fix to be done there, the previously sent patch will make the "pango" backend working fine on DirectFB. The FT2 backend will still result in a blank display. But one working backend would be good enough for us, so please apply. :) I'd like to note that testing the DirectFB backend is not as complicated as it seems: once one a GTK+/DirectFB port is available (e.g. through libgtk-directfb-2.0-dev package on Debian): trunk$ echo system=x11 > ~/.directfbrc trunk$ mkdir pkg-config trunk$ ln -sf /usr/lib/pkgconfig/gtk+-directfb-2.0.pc pkg-config/gtk+-2.0.pc trunk$ PKG_CONFIG_PATH=pkg-config ./configure --disable-maintainer-mode \ --disable-dependency-tracking --disable-python --disable-gnome-pty-helper \ --disable-gtk-doc --without-x --without-xft2 --with-pangox --without-glX trunk$ make trunk$ cd src && ./vte
Chris, is there a penalty to this patch? I kinda like it. Not sure. But I'd rather see the gtk+-directfb bug causing it fixed first...
Oh my. It appears that gdk/directfb has a parallel implementation of gdk_window_schedule_update() and gdk_window_update_idle(), as does gdk/quartz. And because of the layering, neither of those backends are affected by gdk_window_process_all_updates(), belying its name. The only drawback to calling gdk_window_process_updates() directly is that it does not remove the idle update (which should be rectified in gtk+ - though unlikely given the current mess ;-). In short, the patch looks good - though perhaps doing the same thing using two different looping constructs is a little extravagent! Thank you Jérémy for all your hard work in solving this bug.
Actually, since gdk_window_process_all_updates() doesn't do anything, it should not effect the backend idle updates either - which takes me back to square one in trying to understand what's going on here.
Chris, maybe you can clean the gtk+ mess? I mean, you know that code more than anyone around now! ;)
I've commited a variation, r2040: 2008-05-08 Chris Wilson <chris@chris-wilson.co.uk> Bug 516869 – vte displays nothing on GTK+/DirectFB Original patch by Jérémy Bobbio. * src/vte.c (vte_terminal_class_init), (update_regions), (update_repeat_timeout), (update_timeout): gdk_window_process_all_updates() is ineffective on the gtk+-directfb and gtk+-quartz backends, so in order to process updates immediately one must call gdk_window_process_updates() on the desired GdkWindows instead. Which calls gdk_window_process_updates() immediately after invalidating the window in our update timeouts. This should give exactly the same behaviour as doing the call in a second loop over the list of active_terminals (as per the attached patch.) I've left the call to gdk_window_process_all_updates() as on xlib/win32 this should remove the idle source and prevent a spurious GMainContext iteration and should do nothing on directfb/quartz (or any future backend that wishes to do its own thing). Jérémy, John: I'd appreciate it if you could try HEAD and report what happens. Thank you.
(In reply to comment #10) This works great now on gtk+-quartz. tT even runs quickly with VTE_BACKEND=pango. My previous hack to make it work made the Pango backend unbearably slow. This is great. Thanks!
HEAD works fine! Many thanks! I just hope this change does not affect the GTK+/X11 port too much. :)
(In reply to comment #12) > HEAD works fine! Many thanks! Can this bug be closed then?
Yes. :)