GNOME Bugzilla – Bug 503164
Drawing problems for VTE with gtk+-quartz
Last modified: 2008-11-22 14:25:10 UTC
Please describe the problem: Whether using the XFT2 backend or the PANGO backend, there appears to be a problem with how and when redrawing occurs. When running the sample application 'src/vte' the main window has nothing in it and the scroll-bar is transparent (for XFT2 the background is transparent and for PANGO it is white). However, when I resize the window the background turns black and the text begins to draw properly. Steps to reproduce: 1. Build GTK+-quartz using the jhbuild script. Make sure to use the glib patch provided with glib bug http://bugzilla.gnome.org/show_bug.cgi?id=495589. Without this patch the fork call from VTE hangs. 2. Build VTE with 'configure --without-X --enable-debug' 3. Run the 'src/vte' program with either VTE_BACKEND=XFT2 or VTE_BACKEND=PANGO Actual results: Expected results: Does this happen every time? Yes Other information: Attached is a log of the debug information when VTE_DEBUG_FLAGS=UPDATES. I have added extra information in <<<information>>> blocks to help indicate when the resize starts and ends Invalidating all. <<<BEGIN RESIZE>>> vte_terminal_paint (0,0)x(482,314) pixels vte_terminal_paint_area (0,0)x(482,314) pixels, (0,0)x(80,24) cells [(1,1)x(480,312) pixels] vte_terminal_paint (0,0)x(482,314) pixels vte_terminal_paint_area (0,0)x(482,314) pixels, (0,0)x(80,24) cells [(1,1)x(480,312) pixels] vte_terminal_paint (0,0)x(482,314) pixels vte_terminal_paint_area (0,0)x(482,314) pixels, (0,0)x(80,24) cells [(1,1)x(480,312) pixels] vte_terminal_paint (0,0)x(482,314) pixels vte_terminal_paint_area (0,0)x(482,314) pixels, (0,0)x(80,24) cells [(1,1)x(480,312) pixels] vte_terminal_paint (0,0)x(482,314) pixels vte_terminal_paint_area (0,0)x(482,314) pixels, (0,0)x(80,24) cells [(1,1)x(480,312) pixels] vte_terminal_paint (0,0)x(482,314) pixels vte_terminal_paint_area (0,0)x(482,314) pixels, (0,0)x(80,24) cells [(1,1)x(480,312) pixels] vte_terminal_paint (0,0)x(482,314) pixels vte_terminal_paint_area (0,0)x(482,314) pixels, (0,0)x(80,24) cells [(1,1)x(480,312) pixels] vte_terminal_paint (0,0)x(482,314) pixels vte_terminal_paint_area (0,0)x(482,314) pixels, (0,0)x(80,24) cells [(1,1)x(480,312) pixels] vte_terminal_paint (0,0)x(482,314) pixels vte_terminal_paint_area (0,0)x(482,314) pixels, (0,0)x(80,24) cells [(1,1)x(480,312) pixels] <<<END RESIZE>>> Invalidating cursor at (2,48-49). Invalidating cells at (48,2+0)x(1,1). Invalidating pixels at (288,26)x(10,16). Invalidating all. Invalidating all. Invalidating all. Invalidating all. Invalidating all. Invalidating all. Invalidating all. Invalidating all. Invalidating all.
Humm, how do you run the Xft backend if you compiled without X?
Not sure, but it is one of the available backends.
Sorry, I lied. It is just the FT2 backend, not the XFT2 backend.
Ah ok. I'm surprised that the FT2 backend has a grey background (which means it understands translucent background btw). Running "VTE_BACKEND=list vte" shows which backends are compiled in.
The only two listed are FT2 and PANGO
Created attachment 101040 [details] [review] A complete and utter hack to make things work Since there hasn't been movement from the more knowledgable peopl on the bug, I started to poke around. I came up with a hack to make things draw properly, but I think it is very, very inefficient because it forces a complete redraw after each and every character. I couldn't figure out why no redraw was occurring after a keypress. Hopefully this will help someone understand why things are work well.
Chris, any idea what may be wrong? John says vte using gtkquartz is not receiving expose events. Is it perhaps tricked into being fully obscured maybe? John, can you play with terminal->pvt->visibility_state (print it out, etc) to see if that's the problem?
That is definitely one of the problems. I added the following lines to the end of vte_terminal_im_commit to see the state of terminal->pvt->visibility_state after each keypress. _vte_debug_print(VTE_DEBUG_MISC, "Visibility after keypress (%s).\n", visibility_state_str(terminal->pvt->visibility_state)); and the visibility is always GDK_VISIBILITY_FULLY_OBSCURED. I also noted that in the difference between the startup output for VTE on Linux and VTE on gtk+-quartz, Linux has a line "Visibility (fully-obscured -> unobscured).", meaning it received a visibility_notify event.
It appears that the GdkVisibilityNotify is not synthesized for the quartz backend, nor for anything other than X11. Thanks for chasing this one down. r2011: 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.
I think the same fix needs done on lines 8063,8064 of vte.c. At least I had to make that additional change to GDK_VISIBILITY_UNOBSCURED to make it work for me.
In the light of this bug, those lines are redundant. r2016: 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. Right, hopefully that's caught them all!
Closing this in light of the last comment(s) and time elapsed. If there are any more drawing issues specific to gtk-quartz, please open a new bug.