This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: Performance issues -- xdvi
- From: Harold L Hunt II <huntharo at msu dot edu>
- To: cygwin-xfree at cygwin dot com
- Date: Thu, 23 Oct 2003 13:18:01 -0400
- Subject: Re: Performance issues -- xdvi
- References: <3F97E8DB.5090708@northwestern.edu>
- Reply-to: cygwin-xfree at cygwin dot com
Marciano,
XWin.exe is not as fast as Exceed or XWin-32.
Harold
Marciano Siniscalchi wrote:
Running: cygwin 1.5.5-1, XFree 4.3.0 on WinXP in rootless or fullscreen
mode; xwin.log file below.
I have been playing around with xdvi from the latest tetex distribution,
mainly to see if whizzytex (an almost-instant preview package for
emacs/latex/xdvi) could be made to work under Cygwin.
I have found xdvi to be vastly slower under Cygwin/Xfree than under
Linux/Xfree. Displaying a new page takes about 1--1.5 seconds on my P4
2.8 Ghz / 512MB PC. You can see text being displayed almost line by
line. This happens both in "rootless" and "fullscreen" mode. Under
Linux/Xfree, it's almost instantaneous. Under Linux Xfree, xdvi is known
to be pretty fast (faster than Yap under Win32, say).
I should emphasize that, although my goal was to get whizzytex to work,
speed considerations arise when simply previewing a DVI file, by typing
xdvi file.dvi at the bash prompt and then paging through the file with
the keyboard.
I first thought this was due to the Cygwin port of xwin, or to Cygwin
proper, not Cygwin/Xfree. However, I eventually tried the Xwin32 X
server, and was surprised to find out that performance is greatly
improved, very close to "native".
So, the issue seems to be with Cygwin/Xfree. Indeed, I also found out
that other X clients (xterm, emacs) are much snappier under Xwin32 than
under Cygwin/Xfree.
Now, this could be a misconfiguration issue. My xwin.log file is
attached below. I also export DISPLAY=<my machine' IP address>:0 before
running clients. [I have also tried DISPLAY=127.0.0.1:0, but observed no
change in performance, although I recall seeing a thread on the ML
concerning possible differneces]
Otherwise, does anybody have any thoughts? This is probably not a huge
issue for many clients, but the instant-preview nature of whizzytex
makes speed essential (basically, you need to refresh a DVI file every
few keystrokes).
Thanks!
Marciano.
xwin.log file: (running in rootless mode)
ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1280 h 1024
winInitializeDefaultScreens - Returning
OsVendorInit - Creating bogus screen 0
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0000001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winSetEngine - Multi Window => ShadowGDI
winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per
pixel
winCreateBoundingWindowWindowed - User w: 1280 h: 1024
winCreateBoundingWindowWindowed - Current w: 1280 h: 1024
winAdjustForAutoHide - Original WorkArea: 0 0 994 1280
winAdjustForAutoHide - Adjusted WorkArea: 0 0 994 1280
winCreateBoundingWindowWindowed - WindowClient w 1280 h 994 r 1280 l 0 b
994 t 0
winCreateBoundingWindowWindowed - Returning
winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 994
depth: 32
winAllocateFBShadowGDI - Dibsection width: 1280 height: 994 depth: 32
size image: 5089280
winAllocateFBShadowGDI - Created shadow stride: 1280
winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24
bpp 32
winCreateDefColormap - Deferring to fbCreateDefColormap ()
null screen fn ReparentWindow
null screen fn RestackWindow
winFinishScreenInitFB - Calling winInitWM.
InitQueue - Calling pthread_mutex_init
InitQueue - pthread_mutex_init returned
InitQueue - Calling pthread_cond_init
InitQueue - pthread_cond_init returned
winInitWM - Returning.
winFinishScreenInitFB - returning
winScreenInit - returning
InitOutput - Returning.
winInitMultiWindowWM - Hello
winInitMultiWindowWM - Calling pthread_mutex_lock ()
winMultiWindowXMsgProc - Hello
winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
(==) winConfigKeyboard - Layout: "00000409" (00000409)
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)"
Options = "(null)"
winPointerWarpCursor - Discarding first warp: 640 497
winBlockHandler - Releasing pmServerStarted
winInitMultiWindowWM - pthread_mutex_lock () returned.
DetectUnicodeSupport - Windows NT/2000/XP
winInitMultiWindowWM - Calling setlocale ()
winBlockHandler - pthread_mutex_unlock () returned
winInitMultiWindowWM - setlocale () returned
winInitMultiWindowWM - XInitThreads () returned.
winMultiWindowXMsgProc - pthread_mutex_lock () returned.
winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0
winInitMultiWindowWM - pthread_mutex_unlock () returned.
winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0
winMultiWindowXMsgProc - XOpenDisplay () returned and successfully
opened the display.
winInitMultiWindowWM - XOpenDisplay () returned and successfully opened
the display.
winDeinitClipboard - Noting shutdown in progress
winDeinitMultiWindowWM - Noting shutdown in progress
winDeinitClipboard - Noting shutdown in progress
winDeinitMultiWindowWM - Noting shutdown in progress