Menu
▾
▴
#354 auto refresh problem
xvid -version:
< xdvik version 22.84.10 (Xaw toolkit)
Libraries: kpathsea version 3.5.6, T1lib version 5.0.1 >
running on the following system:
< Debian Lenny/Sid with kernel 2.6.24-1-486 >
with Xorg:
<
X.Org X Server 1.4.2
Release Date: 11 June 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian (xorg-server 2:1.4.2-1)
Current Operating System: Linux debianBox 2.6.24-1-486 #1 Thu May 8 01:29:10 UTC 2008 i686
Build Date: 26 June 2008 01:58:50AM >
I'm using Xfce4 and I've justo noticed that the auto refresh feature of xdvi doesn't work when the compositing manager of Xfce is active. I have to press "R" or click in xdvi window to reload the dvi file.
It may an X-related problem.
After clicking the "no-updated" window of xdvi
xwininfo returns:
< xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.
xwininfo: Window id: 0x200001e "xdvik: seminario (4 pages)"
Absolute upper-left X: 6
Absolute upper-left Y: 59
Relative upper-left X: 6
Relative upper-left Y: 27
Width: 715
Height: 665
Depth: 24
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +6+59 -303+59 -303-44 +6-44
-geometry 715x665+0+32 >
while xdpyinfo:
< name of display: :0.0
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 10402000
X.Org version: 1.4.2
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x1a0000f, revert to Parent
number of extensions: 33
BIG-REQUESTS
Composite
DAMAGE
DOUBLE-BUFFER
DPMS
Extended-Visual-Information
GLX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RANDR
RECORD
RENDER
SECURITY
SGI-GLX
SHAPE
SYNC
TOG-CUP
X-Resource
XAccessControlExtension
XC-APPGROUP
XC-MISC
XFIXES
XFree86-Bigfont
XFree86-DGA
XFree86-DRI
XFree86-Misc
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number: 0
number of screens: 1
screen #0:
dimensions: 1024x768 pixels (270x203 millimeters)
resolution: 96x96 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
root window id: 0x57
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 256
preallocated pixels: black 0, white 16777215
options: backing-store NO, save-unders NO
largest cursor: 64x64
current input event mask: 0x7a802c
ButtonPressMask ButtonReleaseMask LeaveWindowMask
ExposureMask StructureNotifyMask SubstructureNotifyMask
SubstructureRedirectMask FocusChangeMask PropertyChangeMask
number of visuals: 17
default visual id: 0x23
visual:
visual id: 0x23
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x24
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x25
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x26
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x27
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x28
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x29
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2a
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2b
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2c
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2d
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2e
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x2f
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x30
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x31
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x32
class: DirectColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits
visual:
visual id: 0x55
class: TrueColor
depth: 32 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff0000, 0xff00, 0xff
significant bits in color specification: 8 bits >
Logged In: YES
user_id=177175
Originator: NO
By 'auto-refresh' you mean you're using the '-watchfile' option of xdvi?
When running 'xdvi -debug events -watchfile 1', do you see output like the
following when recompiling your .tex file, although the window is not updated,
or does the timer not fire at all?
=======
XtAppAddTimeOut: 5000 msecs
events.c:4579: set_timer
=======after set_timer; timers:
timer 0x82b63f8: 1215938652
timer 0x8262ae0: 1215938653
timer 0x82be248: 1215938657
=======
=======XtAppAddTimeOut; timers:
timer 0x82b63f8: 1215938652
timer 0x8262ae0: 1215938653
timer 0x82be248: 1215938657
=======
events.c:5389: EVENT: redraw_page()
events.c:4879: read_events 262143
=======xt_alarm; timers:
timer 0x8262ae0: 1215938653
timer 0x82be248: 1215938657
=======
events.c:5119: EVENT: Redraw 380 x 218 at (0, 0) (base=0,0)
events.c:5123: EVENT: Cursor: 0
events.c:4879: read_events 262142
events.c:5322: EVENT: globals.ev.flags: 3; ev_newpage: 8192, ev_newdoc: 65536, ev_reload: 32768
events.c:4879: read_events 262142
XtAppAddTimeOut: 1000 msecs
events.c:4579: set_timer
=======after set_timer; timers:
timer 0x82b63f8: 1215938654
timer 0x82be248: 1215938657
=======
Logged In: YES
user_id=2145322
Originator: YES
To be more precise, I use xdvi calling it from inside GVim. I think is called without passing any arguments, so the -watchfile option is not involved here. If I don't use the composite manager of Xfce, the xdvi instance (called without arguments) auto reload the .dvi file, so that when I move from GVIM window to xdvi window, the .dvi file changes automatically. With composition, the autoreload feature seems to be inhibited. But I've checked right now that if I call xdvi from shell with the line you suggested 'xdvi -debug events -watchfile 1' I obtain that output and the .dvi file is correctly updated.
Logged In: YES
user_id=177175
Originator: NO
Xdvi doesn't reload the file when only moving to its window, unless the window gets redrawn due to an exposure event (e.g. when it was partially obscured before). If you run xdvi without -watchfile, do you see such lines when running it with '-debug events' (maybe with and without composition) when moving to the xdvi window?
events.c:5322: EVENT: globals.ev.flags: 5; ev_newpage: 8192, ev_newdoc: 65536, ev_reload: 32768
events.c:5119: EVENT: Redraw 237 x 158 at (0, 12) (base=0,0)
Logged In: YES
user_id=2145322
Originator: YES
If I run 'xdvi -debug event filename.dvi' without compositing, every time I switch to xdvi window the output prints the lines
../../../texk/xdvik/events.c:5299: EVENT: globals.ev.flags: 5; ev_newpage: 4096, ev_newdoc: 32768, ev_reload: 16384
../../../texk/xdvik/events.c:5096: EVENT: Redraw 2 x 520 at (145, 58) (base=0,0)
../../../texk/xdvik/events.c:5100: EVENT: Cursor: 0
../../../texk/xdvik/events.c:4855: read_events 131070
and the .dvi file updates correctly. If I run with compositing no Redraw EVENT occurs and switching between xdvi window and another one doesn't produce further output.
Logged In: YES
user_id=177175
Originator: NO
OK, so there could be several reasons for this behaviour:
- xdvi somehow handles expose events incorrectly, ie. in a manner
that doesn't work with the compositing mode of the WM
- the compositing mode optimizes away some expose events so that
xdvi doesn't see them at all
So when you tested this, there was e.g. part of the window obscured
by another window and the window then raised and redrawn, without xdvi
getting an expose event?
Logged In: YES
user_id=2145322
Originator: YES
Yes, I've tested in this situation. Gvim window opened; xdvi and terminal windows opened. After running latex from inside Gvim, I run 'xdvi -debug event filname.dvi' from terminal. After that I have the xdvi window partially obscured by the terminal. If I switch to xdvi with ALT-tab (with compositing) no refresh occurs (and no Redraw EVENT is printed in the termianl). Same thing if I pass to xdvi clicking with the mouse on the top of the window. To reload the file I need to click in the text inside xdvi window. Without compositing, forgrounding xdvi window with ALT-tab is enough to have the .dvi file reloaded automatically.
Logged In: YES
user_id=177175
Originator: NO
Sorry, I can't find anything wrong with xdvi's event handling at this point (and I can't easily install xfce since my gnome libraries are too old); this will have to be debugged by someone with more experience in X event handling issues.
I have the same problem. In response to stefanulrich
> By 'auto-refresh' you mean you're using the '-watchfile' option of xdvi?
yes
> When running 'xdvi -debug events -watchfile 1', do you see output like the
> following when recompiling your .tex file, although the window is not updated,
> or does the timer not fire at all
The timer doesn't fire after an ALT-TAB
There is no debugging output until one switches to the window AND
either clicks the mouse or hits a key