After upgrading to Xorg-x11-7.4-r1, Xterm & Xpdf take 5 - 6 seconds to open. Previously, they opened after 1 - 2 seconds. Reproducible: Always Steps to Reproduce: 1. open 'xterm' or 'xpdf' 2. count seconds 3. Actual Results: Count reached 5 or 6 before Xterm or Xpdf opened. Expected Results: Count of seconds should be 1 or 2 before the apps open. I have asked about this on Gentoo-user mailing list & others have experienced it. I have updated to the latest testing versions of Nvidia & Xterm and the problem persists. I will attach the usual 'emerge --info' result & also the result of running 'strace xterm': the problem seems to be "resource unavailable".
Created attachment 210770 [details] result of 'emerge --info'
Created attachment 210772 [details] result of 'strace xterm'
Please provide your xorg.conf and your Xorg.0.log. You're probably trying to load a font you no longer have. Try either installing the missing font or try changing the xterm and xpdf confs to load another font ("fixed" is always available, albeit being ugly). Thanks
I've tried 'xterm -fn fixed' with no change in the delay. Every time I start Xterm from CLI, I get 'Warning: Missing charsets in String to FontSet conversion'. I don't have a ~/.Xdefaults file. All 6 dirs named in xorg.conf exist & have fonts in them. In the fonts menu in the toolbar, I have 'Default ... Packed font ... Double-sized characters ... UTF8 ... Allow Termcap ops ... Allow Fonts ops ... Allow Title ops' ('Packed' & 'UTF8' are blurred out). I will attach xorg.conf & the latest /var/log/Xorg.0.log . I will also attach a screenshot of a typical Xterm session started from CLI with the command 'xterm': I believe I'm using 'fixed'.
Created attachment 211943 [details] xorg.conf
Created attachment 211944 [details] Xorg.0.log
Created attachment 211946 [details] screenshot of Xterm started by 'xterm' from XLI
I have found a solution to the problem thanks to Thomas Dickey, the maintainer of Xterm. He says: The most common reason for slow startup for xterm in a UTF-8 locale is a long-ago i18n "fix" in the X libraries that makes the Athena widgets ask for a fontset which includes a large number of (large) fonts. I made a workaround a few years ago, adding a resource "menuLocale" (see manpage). The scenario only happens on systems with a large number of large bitmap fonts to choose from. I added a line 'XTerm*menuLocale: C' to my ~/.Xresources file, ran 'xrdb -merge ~/.Xresources' to source the change & Xterm starts up without any delay. NB it's 'XTerm', not 'Xterm'.
Shortly after my previous msg, the problem re-appeared. The cause may have been somewhere among pkgs I emerged in the interim, ie 'mpfr net-tools gdbm readline glibc xulrunner firefox openoffice ncurses'. I have had further discussions with TD the maintainer of Xterm & have found a simple but incomplete method of fixing the problem. TD has a FAQ : http://invisible-island.net/xterm/xterm.faq.html#slow_menus He also says : at some point, several years ago, someone decided to improve the way the Athena widgets used for Xterm's menus handled i18n by creating a font-set from all of the available fonts for the current locale. when used in an environment where there are many CJK etc fonts, this is very slow. So I added the menuLocale resource to override Xterm's locale as seen by the initialization code. This work-around does not solve the problem for me, but simply emerging with USE="-toolbar" removes the delay when starting Xterm. Unfortunately, the delay is only moved to starting the 1st pop-up menu with Ctl-click.
I've tried running xpdf as $ LC_CTYPE=C xpdf and it seemed to me that utf8 really is the culprit. I created a patch with a workaround similar to the one xterm uses. I'm attaching it and the modified ebuild. You also need to execute the following commands for it to work: $ echo 'xpdf*toolbarLocale: C' >>~/.Xresources $ echo 'xpdf*menuLocale: C' >>~/.Xresources $ xrdb -merge ~/.Xresources
Created attachment 222489 [details, diff] workaround for slow startup of Xpdf in a UTF-8 locale
Created attachment 222491 [details] the modified ebuild which applies the patch
Do you want me to test this via a local overlay or is it going into the tree ? Thanks for getting around to fixing it (hopefully).
(In reply to comment #13) > Do you want me to test this via a local overlay or is it going into the tree ? > Thanks for getting around to fixing it (hopefully). > Hi Philip, I haven't created a bug for the Ebuild yet. It would be great if you could test it from an overlay. Thanks, Csabi
*** Bug 308519 has been marked as a duplicate of this bug. ***
Looks like it should be fixed in xpdf.
I downloaded your 2 files & copied the ebuild to /var/lib/layman/local after adding a line to /etc/make.conf 'PORTDIR_OVERLAY=/var/lib/layman/local'. Then (in the overlay dir) I entered 'emerge -pv xpdf-3.02-r4.ebuild', which failed with these lines : *** emerging by path is broken and may not always work!!! These are the packages that would be merged, in order: Calculating dependencies... done! Traceback (most recent call last): File "/usr/bin/emerge", line 42, in <module> retval = emerge_main() File "/usr/lib64/portage/pym/_emerge/main.py", line 1393, in emerge_main myopts, myaction, myfiles, spinner) File "/usr/lib64/portage/pym/_emerge/actions.py", line 276, in action_build settings, trees, myopts, myparams, myaction, myfiles, spinner) File "/usr/lib64/portage/pym/_emerge/depgraph.py", line 5430, in backtrack_depgraph myaction, myfiles, spinner) File "/usr/lib64/portage/pym/_emerge/depgraph.py", line 5448, in _backtrack_depgraph success, favorites = mydepgraph.select_files(myfiles) File "/usr/lib64/portage/pym/_emerge/depgraph.py", line 1582, in select_files "%s is not in a valid portage tree hierarchy or does not exist" % x) PackageNotFound: xpdf-3.02-r4.ebuild is not in a valid portage tree hierarchy or does not exist If you want me to test your ebuild + patch, you need to tell me how to do so in a bit more detail (smile).
(In reply to comment #17) > I downloaded your 2 files & copied the ebuild to /var/lib/layman/local > after adding a line to /etc/make.conf 'PORTDIR_OVERLAY=/var/lib/layman/local'. > Then (in the overlay dir) I entered 'emerge -pv xpdf-3.02-r4.ebuild', > which failed with these lines : > > *** emerging by path is broken and may not always work!!! > These are the packages that would be merged, in order: > Calculating dependencies... done! > Traceback (most recent call last): > File "/usr/bin/emerge", line 42, in <module> > retval = emerge_main() > File "/usr/lib64/portage/pym/_emerge/main.py", line 1393, in emerge_main > myopts, myaction, myfiles, spinner) > File "/usr/lib64/portage/pym/_emerge/actions.py", line 276, in action_build > settings, trees, myopts, myparams, myaction, myfiles, spinner) > File "/usr/lib64/portage/pym/_emerge/depgraph.py", line 5430, in > backtrack_depgraph > myaction, myfiles, spinner) > File "/usr/lib64/portage/pym/_emerge/depgraph.py", line 5448, in > _backtrack_depgraph > success, favorites = mydepgraph.select_files(myfiles) > File "/usr/lib64/portage/pym/_emerge/depgraph.py", line 1582, in select_files > "%s is not in a valid portage tree hierarchy or does not exist" % x) > PackageNotFound: xpdf-3.02-r4.ebuild is not in a valid portage tree hierarchy > or does not exist > > If you want me to test your ebuild + patch, > you need to tell me how to do so in a bit more detail (smile). > Hi Philip, Create the proper directory structure: # mkdir -p /var/lib/layman/local/app-text/xpdf/files Copy the ebuild and the patch: # cp xpdf-3.02-r4.ebuild /var/lib/layman/local/app-text/xpdf/ # cp xpdf-3.02-poppler-toolbar-and-menu-locale.patch /var/lib/layman/local/app-text/xpdf/files/ Create the manifest for the package: # ebuild /var/lib/layman/local/app-text/xpdf/xpdf-3.02-r4.ebuild manifest Emerge it by atom: # emerge xpdf It's also a good idea to mask newer versions of the package: # mkdir -p /etc/portage/package.mask # echo '>app-text/xpdf-3.02-r4' >/etc/portage/package.mask/xpdf Cheers, Csabi P.S.: Don't forget to set up the X resources.
Thanks for the more detailed help. I believed I had a note in my files re how to run a patched ebuild, but it was something different. I will add your instructions to my home-made 'gentoo.ref' file. I followed the instructions & after all that, Xpdf starts immediately. It's not clear to me why Portage uses the local overlay, but perhaps that's the default, if there is a choice. So thanks also for the work writing the patch & it sb safe to commit it to the tree.
(In reply to comment #19) > Thanks for the more detailed help. I believed I had a note in my files > re how to run a patched ebuild, but it was something different. > I will add your instructions to my home-made 'gentoo.ref' file. > > I followed the instructions & after all that, Xpdf starts immediately. > It's not clear to me why Portage uses the local overlay, > but perhaps that's the default, if there is a choice. > > So thanks also for the work writing the patch > & it sb safe to commit it to the tree. > Hi Philip, I'm glad it all worked out for you. Regards, Csabi
Thanks, this workaround helped me too. But maybe einfo / ebuild should tell the user that he has to do $ echo 'xpdf*toolbarLocale: C' >>~/.Xresources $ echo 'xpdf*menuLocale: C' >>~/.Xresources $ xrdb -merge ~/.Xresources from comment 10. I don't know if it is a good idea if the ebuild do these steps by default for all users.
(In reply to comment #21) > Thanks, > this workaround helped me too. But maybe einfo / ebuild should tell the user > that he has to do > $ echo 'xpdf*toolbarLocale: C' >>~/.Xresources > $ echo 'xpdf*menuLocale: C' >>~/.Xresources > $ xrdb -merge ~/.Xresources > from comment 10. I don't know if it is a good idea if the ebuild do these steps > by default for all users. > Hi Jan, You're right, the user should be informed. I've added a couple of elog messages with a link to comment 10. Cheers, Csabi
Created attachment 228453 [details] the modified ebuild which applies the patch added a couple of elog messages
(In reply to comment #8) > I have found a solution to the problem thanks to Thomas Dickey, the maintainer > of Xterm. He says: > > The most common reason for slow startup for xterm in a UTF-8 locale > is a long-ago i18n "fix" in the X libraries that makes the Athena widgets > ask for a fontset which includes a large number of (large) fonts. > I made a workaround a few years ago, adding a resource "menuLocale" > (see manpage). > > The scenario only happens on systems > with a large number of large bitmap fonts to choose from. > > I added a line 'XTerm*menuLocale: C' to my ~/.Xresources file, > ran 'xrdb -merge ~/.Xresources' to source the change > & Xterm starts up without any delay. This workaround worked for me until i updated from xterm-250 to xterm-262 due the stableaziation of the latter via bug 336745 and bug 339640. There was a change in the menuLocale stuff in Patch 257 <http://invisible-island.net/xterm/xterm.log.html#xterm_257>: - corrected logic for menuLocale resource; the setlocale function returns the original locale only when querying. - change default value of menuLocale resource to "C", to work around longstanding Xorg bug. I'll check if these changes caused the regression. Is anybody else facing this regression?
(In reply to comment #24) > (In reply to comment #8) > > I added a line 'XTerm*menuLocale: C' to my ~/.Xresources file, > > ran 'xrdb -merge ~/.Xresources' to source the change > > & Xterm starts up without any delay. > > This workaround worked for me until i updated from xterm-250 to xterm-262 due > the stableaziation of the latter via bug 336745 and bug 339640. > > There was a change in the menuLocale stuff in Patch 257 > <http://invisible-island.net/xterm/xterm.log.html#xterm_257>: > - corrected logic for menuLocale resource; the setlocale function returns the > original locale only when querying. > - change default value of menuLocale resource to "C", to work around > longstanding Xorg bug. > > I'll check if these changes caused the regression. Patch 257 definitively causes this regression for me.
I'm quite sure #71747 and https://bugs.freedesktop.org/show_bug.cgi?id=4939 are related. LC_CTYPE=C xcalc vs LC_CTYPE=en_US.utf-8 xcalc
(In reply to comment #26) > I'm quite sure #71747 and https://bugs.freedesktop.org/show_bug.cgi?id=4939 are > related. > LC_CTYPE=C xcalc vs LC_CTYPE=en_US.utf-8 xcalc Xpdf still shows the same 6 s delay with the latter Ctype, but starts at once with the former 'C' Ctype. Tom Dickey's explanation seems correct, but it hasn't been applied to all the affected apps.
shouldve known b.g.o has something about this :> i also discovered now that doing "XTerm*toolBar: false" cut xterm startup time down from several seconds to almost instant. running xterm-266.
Vanished into thin air.
