Mon 10 Jul 2017 12:40:34 PM UTC, comment #32:
Bug still exists with octave-4.2.1 on Windows 7 64, 32 and 64 bit, zip file.
Cache is generated once upon every octave start, manually running fc_update does not fix this. Resmon shows that octave-gui.exe is reading every font file (this is a rudimentary progress display since it scans them in alphabetic order). Every plotting after the initial plot works normally (= fast).
Installed version does not suffer from this problem.
|
Sun 19 Feb 2017 07:20:26 PM UTC, comment #31:
After a fresh Windows 10 install, and a fresh Octave 4.2.0 install it takes quite some time before the plot in the first plotting window appears after e.g. a plot(x,y) command. It looks like the "Figure 1" window is blocked (or hanging). So the window is there but the content (the plot) is not plotted.
After some time this behavior disappears, and after first plots have been made successfully, visualizing plotting becomes faster, although resizing the window now takes a lot of time. The plot is not redrawn, and one needs to use the circular arrow (redo) button to get the desired result (after some time).
This behavior persists.
Windows 10 & Octave still seem to have difficulties.
|
Thu 29 Dec 2016 10:03:42 PM UTC, comment #30:
Are there any other places that this fontcache delay will come up that may or may not be fixed (or at least improved) with this patch? From what I read, win installer will run fc-cache. so if no new fonts are installed the slowdown should be gone. but if a new font is added... how does that trigger re-running the cache-update process? will that be manual or automatic?
For zip-installers, should running the fc-update.bat be a one-time thing? or something to be run everytime octave starts?
Last, the only other delay in windows that seemed similar was seemingly random delayed calls to the pager. It doesn't seem like this would be related, but would someone with procmon be able to verify?
|
Thu 29 Dec 2016 09:44:18 PM UTC, comment #29:
note: Another potential duplicate of this (now hopefully fixed bug) is bug #44471.
|
Thu 01 Dec 2016 07:27:14 PM UTC, comment #28:
fixed
|
Thu 01 Dec 2016 07:16:09 PM UTC, comment #27:
typo in the fc-update.bat:
echo "Updating fc-cache (may take a file) ..."
|
Thu 01 Dec 2016 06:46:41 PM UTC, comment #26:
Pushed http://hg.octave.org/mxe-octave/rev/7f2d5c8c4491
which adds running fc-cache in the installer.
There is also a fc_update.bat script in the base of the files, so should be available to un manually in the zipfile as well
|
Thu 17 Nov 2016 02:00:10 PM UTC, comment #25:
would also be useful if there was a fix for those using the zip-file to 'install'
|
Mon 17 Oct 2016 07:24:59 PM UTC, comment #24:
Would maybe make more sense at that point to just run fc-cache within the installer.
The other issue is also that as soon as another application installs an additional font, octave will then show the same issue.
|
Mon 17 Oct 2016 07:09:19 PM UTC, comment #23:
So what about opening a figure as part of the installation?
|
Mon 17 Oct 2016 12:06:46 PM UTC, comment #22:
For info, trying v2.12.0 doesn't show any speed increase - same 20+ second delay first time a plot is ever generated (when no fontconfig cache was available)
|
Sun 16 Oct 2016 12:42:31 PM UTC, comment #21:
For windows, could maybe try updating the versuion of fontconfig and see if that helps.
version used is 2.11.1 was released March 2014, latest version looks like 2.12.0, released June 2016.
|
Sun 16 Oct 2016 04:45:04 AM UTC, comment #20:
Is it possible to plot a test figure during Octave installation, so the delay in the building of fontconfig directory will be part of the installation?
|
Sat 15 Oct 2016 07:09:51 PM UTC, comment #19:
Bug #49300 reports the same delay on the first plot on MacOS 10.12 (Sierra). On Stackoverflow there are reports that this can take up to 3min. I think the solution here would be really a popup window with a progressbar to inform the user.
|
Wed 16 Mar 2016 05:19:47 PM UTC, comment #18:
I could get the 30+ sec delay on my windows 7 machine if I delete the fontcache from %LOCALAPPDATA%\fontconfig
After it generated it, I didn't have any delays, not any issues with later runs of octave plotting
Looking around, on mine, no fontconfig cache was added to %TEMP%, so no potential issues on reboots.
|
Wed 27 Jan 2016 04:22:30 PM UTC, comment #17:
It sounds so. In my windows 7 I had slow executing only the very first time I launched octave and plotted.
After your suggestion, I deleted the font cache, that is in
C:\Windows\ServiceProfiles\LocalService\AppData\Local
and not %TEMP%
and back again it was slow.
|
Wed 13 Jan 2016 09:23:03 PM UTC, comment #16:
Is it possible that the fontconfig chache is generated in %TEMP%\fontconfig\cache and some users have settings/tools which clear the %TEMP% folder on startup?
This could explain why some users see the delay only once if the a plot is shown, some others between restarts and others between logoff/login.
See also http://sourceforge.net/p/mplayerwin/bugs/1/
perhaps we can move the fontconfig cache to the Octave install directory
|
Tue 24 Nov 2015 09:02:59 PM UTC, comment #15:
@Julien: your comment makes me think that cache files are stored in a "volatile" dir such as /tmp on linux, erased after closing a user session. Where are cache files stored on windows? What is the value of fontconfig configure options "--localstatedir" (or better "--with-cache-dir=DIR") in mxe?
Also is fc-cache installed along with mxe-octave? If so can you try to run it prior to your first plot in a windows session? Something like:
|
Tue 24 Nov 2015 04:53:16 PM UTC, comment #14:
This fontconfig bug report may be relevant: https://bugs.freedesktop.org/show_bug.cgi?id=64766
It is suggested in the bug log that perhaps fontconfig is not well suited for non-GNU/Linux systems (no idea of the authority or veracity of that claim).
|
Tue 24 Nov 2015 04:30:14 PM UTC, comment #13:
Cool, at least now we have a suspect. Thank you Andrea for investigating this.
Assuming that it is indeed fontconfig initializing its font files cache that is the cause of the problem, I think that:
a) Doing it at startup with an explicit wait message, as suggested by Pantxo, would of course be much better than having Octave frozen for 40s, without explanation, when the first figure is created.
b) But even this would be slightly annoying, I think. One thing that I love about Octave, is that is starts quickly. Do I really have to wait 40 seconds when I start Octave GUI for the first time in a given Windows session? I would prefer not to...
Wouldn't it be possible to scan for font files when Octave is installed, and then provide a command somewhere in a menu to rescan if needed?
|
Wed 11 Nov 2015 10:47:35 AM UTC, comment #12:
So it looks like the freeze is due to fontconfig initializing its font files cache. What about calling "FcInit ()" (currently in "txt-eng-ft.cc (ft_manager::ft_manager)") at startup and displaying a splash screen as proposed in bug #41088?
AFAIR this is what GIMP does on mac, clearly stating that it is loading font files.
|
Wed 04 Nov 2015 03:17:30 PM UTC, comment #11:
One more piece of information. Same problem, win 7 64 bit. First time plotting hangs for a while, later plots are OK.
I tried debuggining with procmon, and I fìdiscover that -while hanging- it is actually reading (or scanning) all the fonts file in windows/font folder, in alphabetic oder from the first to the last: they are > 400 files there.
|
Fri 25 Sep 2015 02:50:37 PM UTC, comment #10:
One more piece of information: during the 40 second delay that I observe, the memory occupied by octave-gui.exe goes up from 32Mo to roughly 70Mo, then fluctuates and finally stabilizes around 50Mo (>> 32 Mo).
|
Fri 25 Sep 2015 02:47:56 PM UTC, comment #9:
@Philip (answering message on maintainers list)
http://octave.1599824.n4.nabble.com/Input-needed-for-bug-report-45458-td4672663.html#a4672664
1) Based on my experiments, the problem is unrelated with the creation of qt-settings (see Comment #5).
2) The problem appears both with the CLI and with the GUI. The delay that I observe is the same in both cases (approx. 40s) and it is also the same with qt/fltk/gnuplot.
|
Fri 25 Sep 2015 02:41:47 PM UTC, comment #8:
@Andreas (comment #7):
1) I am surprised that your colleagues sees the problem disappear after a reboot. In my case, a simple close/repon of my session is enough to make it re-appear. Are you sure about that?
2) The process that uses CPU time is octave-gui.exe, but it only takes 13% approximately.
|
Fri 25 Sep 2015 12:16:03 PM UTC, comment #7:
A colleague tried GNU Octave 4.0 MXE build on Win7 64bit. The first plot was very slow (30s for plot (1:10)) and afterwards fast as expected even after deleting .config/octave or reboot.
Do you see which process uses CPU in task-manager?
|
Thu 24 Sep 2015 09:59:58 AM UTC, comment #6:
One more piece of information: the Win7/64 machine where the problem occurs has a roaming user profile, while the Win7/32 has not. Perhaps is it relevant...
@Heinz-Georg Fehn: do you have a romaing profile as well?
|
Thu 24 Sep 2015 09:47:00 AM UTC, comment #5:
Some more information regarding this problem:
1) I also have a Win7/32bit machine, but I don't see the problem there. I have no idea if this 32bits/64bits difference is relevant...
2) I have true deleting .config/octave/qt-settings as suggested by Dan. When I close and re-open Octave, qt-settings is created, but the problem does not reappear. It only reappaears if I close my Windows session and log in again.
I really don't have a clue about what's going on.
|
Mon 21 Sep 2015 03:14:54 PM UTC, comment #4:
I just observed exactly the same problem (Win7/64, Octave 4.0.0).
The first plotting command taks a very long time to succeed. But then, successive plotting commands are fast as expected.
It remains fast if I close Octave and restart, within the same Windows sessions.
The problem comes back if I close my Windows session and open a new one.
I will try to see what happens if I deleter some settings files...
|
Sat 11 Jul 2015 05:19:22 PM UTC, comment #3:
Strange one, and unfortunately difficult to debug without consistency. Could you try deleting or renaming your settings file and relaunch to see if the delay occurs again? The file on Linux is located in
.config/octave/qt-settings
|
Tue 07 Jul 2015 08:55:40 AM UTC, comment #2:
Thank you for your answer, but the problem occurs using 'qt'.
The main problem was the response time for generating the first plot. After installing qctave again and waiting for 1 min calling plot(1:10) the figure and the content in it was correct.
After that, the response time for plots are okay. It looks that this problem occurs only in initialization the features for 'qt'.
Best regards
Heinz-Georg Fehn
|
Tue 07 Jul 2015 08:06:16 AM UTC, comment #1:
When changing to gnuplot, you might have to create a new figure.
Does gnuplot work for plotting then?
|
Wed 01 Jul 2015 07:55:13 PM UTC, original submission:
using octave 4.0.0-0 it run including plot. After run matlab Version 2014b 64 bit once on Windows 7 octave could not motivated to go on with the plot command plot(1:10). It freezes. Other elements which does not use figures or plot work well. I tryed to change graphics to gnuplot, but nothing is going on.
Deinstalling and installing octave again leads to the same Problem.
What is the reason and do you need any more information please let me know it.
|