gnuplot-beta

Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

Dear gnuplot-beta list members,

I had to do some work with gnuplot on a windows machine, and I've have
some comments on the windows version of 4.6rc1.

- I agree with the previous discussion that the old style zip package
has to be provided as an alternative, but overall I think it's good that
we finally have an installer. For the majority of windows users, this is
what makes sense, while they are unfamiliar with zip packages.

- The installer opens the windows-specific readme file at the end of the
installation, however, the file appears garbled in Notepad because the
line endings are \n instead of \r\n which is usual on windows. Most
editors can handle this but Notepad (at least on Vista) can't.

- On one of my machines, startup appeared to be extremely slow, taking
about 5 minutes (!). This is true for both the console and GUI versions.
For the first few tries I've actually killed the process, because I
didn't have the patience to wait it out. Once it started, it appeared to
work normally, there were no delays and plotting was instantaneous as
well. (Older versions had a long delay at the first plot because of
fontconfig or whatever.)
This happened in both interactive and non-interactive mode, however,
only on a virtual machine running Vista. On a real computer running
Windows 7, startup was instantaneous.
I have no idea what causes this, and why it appears on one machine but
doesn't on the other. Have any of you experienced anything similar?
I think this issue is potentially serious, because those who meet with
it unsuspectingly may end up thinking that gnuplot is completely useless
- "I've clicked on the icon", they would say, "but nothing happened!"

- The reworked windows terminal is awesome! To everyone who contributed
to it: good work! I miss the "previous zoom" button from the wxt
terminal, though.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

[Ethan A M. <sf...@us...>]

On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> 
> - On one of my machines, startup appeared to be extremely slow, taking
> about 5 minutes (!). This is true for both the console and GUI versions.
> For the first few tries I've actually killed the process, because I
> didn't have the patience to wait it out. Once it started, it appeared to
> work normally, there were no delays and plotting was instantaneous as
> well. (Older versions had a long delay at the first plot because of
> fontconfig or whatever.)
> This happened in both interactive and non-interactive mode, however,
> only on a virtual machine running Vista. On a real computer running
> Windows 7, startup was instantaneous.

I seem to recall this was discussed a couple of years ago.
The issue then was that if the program did not find a certain set of fonts, 
it triggered creation of a bitmap font set from the underlying font
descriptions.  This was painfully slow but only  happened the first time, 
since subsequent runs would find the  now-created font set.  
However, I wonder if you run under a virtual machine whether every time 
is a "first" time?  Anyhow, my best guess is that this is a font issue
rather than anything to do with gnuplot per se.

	Ethan

> I have no idea what causes this, and why it appears on one machine but
> doesn't on the other. Have any of you experienced anything similar?
> I think this issue is potentially serious, because those who meet with
> it unsuspectingly may end up thinking that gnuplot is completely useless
> - "I've clicked on the icon", they would say, "but nothing happened!"
> 
> - The reworked windows terminal is awesome! To everyone who contributed
> to it: good work! I miss the "previous zoom" button from the wxt
> terminal, though.
> 
> Péter Juhász
> 

Re: Observations on the 4.6rc1 windows package

[Bastian M. <bma...@we...>]

Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
>>
>> - On one of my machines, startup appeared to be extremely slow, taking
>> about 5 minutes (!). This is true for both the console and GUI versions.
>> For the first few tries I've actually killed the process, because I
>> didn't have the patience to wait it out. Once it started, it appeared to
>> work normally, there were no delays and plotting was instantaneous as
>> well. (Older versions had a long delay at the first plot because of
>> fontconfig or whatever.)
>> This happened in both interactive and non-interactive mode, however,
>> only on a virtual machine running Vista. On a real computer running
>> Windows 7, startup was instantaneous.
>
> I seem to recall this was discussed a couple of years ago.
> The issue then was that if the program did not find a certain set of fonts,
> it triggered creation of a bitmap font set from the underlying font
> descriptions.  This was painfully slow but only  happened the first time,
> since subsequent runs would find the  now-created font set.
> However, I wonder if you run under a virtual machine whether every time
> is a "first" time?  Anyhow, my best guess is that this is a font issue
> rather than anything to do with gnuplot per se.
>
> 	Ethan
>

The cairo terminals no longer use the fontconfig mechanism of Windows, 
so this particular issue should have been solved.
On the other hand I vaguely remember a similar report a while ago, but I 
couldn't reproduce on various XP, Vista and 7 machines.

   Bastian

>> I have no idea what causes this, and why it appears on one machine but
>> doesn't on the other. Have any of you experienced anything similar?
>> I think this issue is potentially serious, because those who meet with
>> it unsuspectingly may end up thinking that gnuplot is completely useless
>> - "I've clicked on the icon", they would say, "but nothing happened!"
>>
>> - The reworked windows terminal is awesome! To everyone who contributed
>> to it: good work! I miss the "previous zoom" button from the wxt
>> terminal, though.
>>
>> Péter Juhász
>>

Re: Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> 
> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> > On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> >>
> >> - On one of my machines, startup appeared to be extremely slow, taking
> >> about 5 minutes (!). This is true for both the console and GUI versions.
> >> For the first few tries I've actually killed the process, because I
> >> didn't have the patience to wait it out. Once it started, it appeared to
> >> work normally, there were no delays and plotting was instantaneous as
> >> well. (Older versions had a long delay at the first plot because of
> >> fontconfig or whatever.)
> >> This happened in both interactive and non-interactive mode, however,
> >> only on a virtual machine running Vista. On a real computer running
> >> Windows 7, startup was instantaneous.
> >
> > I seem to recall this was discussed a couple of years ago.
> > The issue then was that if the program did not find a certain set of fonts,
> > it triggered creation of a bitmap font set from the underlying font
> > descriptions.  This was painfully slow but only  happened the first time,
> > since subsequent runs would find the  now-created font set.
> > However, I wonder if you run under a virtual machine whether every time
> > is a "first" time?  Anyhow, my best guess is that this is a font issue
> > rather than anything to do with gnuplot per se.
> >
> > 	Ethan
> >
> 
> The cairo terminals no longer use the fontconfig mechanism of Windows, 
> so this particular issue should have been solved.
> On the other hand I vaguely remember a similar report a while ago, but I 
> couldn't reproduce on various XP, Vista and 7 machines.
> 

On further testing I've noticed that there *is* a slight delay on
startup even on the Win7 machine (4-5 seconds). This means that even
something like 'gnuplot -e "print 1"' takes this much time.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

[Bastian M. <bma...@we...>]

Am 17.02.2012 19:16, schrieb Juhász Péter:
> On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
>>
>> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
>>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
>>>>
>>>> - On one of my machines, startup appeared to be extremely slow, taking
>>>> about 5 minutes (!). This is true for both the console and GUI versions.
>>>> For the first few tries I've actually killed the process, because I
>>>> didn't have the patience to wait it out. Once it started, it appeared to
>>>> work normally, there were no delays and plotting was instantaneous as
>>>> well. (Older versions had a long delay at the first plot because of
>>>> fontconfig or whatever.)
>>>> This happened in both interactive and non-interactive mode, however,
>>>> only on a virtual machine running Vista. On a real computer running
>>>> Windows 7, startup was instantaneous.
>>>
>>> I seem to recall this was discussed a couple of years ago.
>>> The issue then was that if the program did not find a certain set of fonts,
>>> it triggered creation of a bitmap font set from the underlying font
>>> descriptions.  This was painfully slow but only  happened the first time,
>>> since subsequent runs would find the  now-created font set.
>>> However, I wonder if you run under a virtual machine whether every time
>>> is a "first" time?  Anyhow, my best guess is that this is a font issue
>>> rather than anything to do with gnuplot per se.
>>>
>>> 	Ethan
>>>
>>
>> The cairo terminals no longer use the fontconfig mechanism of Windows,
>> so this particular issue should have been solved.
>> On the other hand I vaguely remember a similar report a while ago, but I
>> couldn't reproduce on various XP, Vista and 7 machines.
>>
>
> On further testing I've noticed that there *is* a slight delay on
> startup even on the Win7 machine (4-5 seconds). This means that even
> something like 'gnuplot -e "print 1"' takes this much time.
>
> Péter Juhász
>

Finally, I have been able to reproduce this delay on a Vista machine 
using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
4.5 build which does not include cairo and wxt terminals does not show 
the delay on start-up.
Also, I do not see any notable delay using my own build (including wxt 
and cairo), see
http://gnuplot.info/development/binaries/
Is anybody able to reproduce this observation?

   Bastian

Re: Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

On Sat, 2012-02-25 at 09:04 +0100, Bastian Märkisch wrote:
> Am 17.02.2012 19:16, schrieb Juhász Péter:
> > On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> >>
> >> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> >>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> >>>>
> >>>> - On one of my machines, startup appeared to be extremely slow, taking
> >>>> about 5 minutes (!). This is true for both the console and GUI versions.
> >>>> For the first few tries I've actually killed the process, because I
> >>>> didn't have the patience to wait it out. Once it started, it appeared to
> >>>> work normally, there were no delays and plotting was instantaneous as
> >>>> well. (Older versions had a long delay at the first plot because of
> >>>> fontconfig or whatever.)
> >>>> This happened in both interactive and non-interactive mode, however,
> >>>> only on a virtual machine running Vista. On a real computer running
> >>>> Windows 7, startup was instantaneous.
> >>>
> >>> I seem to recall this was discussed a couple of years ago.
> >>> The issue then was that if the program did not find a certain set of fonts,
> >>> it triggered creation of a bitmap font set from the underlying font
> >>> descriptions.  This was painfully slow but only  happened the first time,
> >>> since subsequent runs would find the  now-created font set.
> >>> However, I wonder if you run under a virtual machine whether every time
> >>> is a "first" time?  Anyhow, my best guess is that this is a font issue
> >>> rather than anything to do with gnuplot per se.
> >>>
> >>> 	Ethan
> >>>
> >>
> >> The cairo terminals no longer use the fontconfig mechanism of Windows,
> >> so this particular issue should have been solved.
> >> On the other hand I vaguely remember a similar report a while ago, but I
> >> couldn't reproduce on various XP, Vista and 7 machines.
> >>
> >
> > On further testing I've noticed that there *is* a slight delay on
> > startup even on the Win7 machine (4-5 seconds). This means that even
> > something like 'gnuplot -e "print 1"' takes this much time.
> >
> > Péter Juhász
> >
> 
> Finally, I have been able to reproduce this delay on a Vista machine 
> using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
> 4.5 build which does not include cairo and wxt terminals does not show 
> the delay on start-up.
> Also, I do not see any notable delay using my own build (including wxt 
> and cairo), see
> http://gnuplot.info/development/binaries/
> Is anybody able to reproduce this observation?
> 
>    Bastian


Thanks for the followup. 

I did use Tatsuro Matsuoka's "full" win32 package. With that, I observed
a startup delay of a few seconds on all (real) windows machines I've
tried.
I haven't tried other builds yet, but I'll try them today.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

On Sat, 2012-02-25 at 09:04 +0100, Bastian Märkisch wrote:
> Am 17.02.2012 19:16, schrieb Juhász Péter:
> > On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> >>
> >> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> >>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> >>>>
> >>>> - On one of my machines, startup appeared to be extremely slow, taking
> >>>> about 5 minutes (!). This is true for both the console and GUI versions.
> >>>> For the first few tries I've actually killed the process, because I
> >>>> didn't have the patience to wait it out. Once it started, it appeared to
> >>>> work normally, there were no delays and plotting was instantaneous as
> >>>> well. (Older versions had a long delay at the first plot because of
> >>>> fontconfig or whatever.)
> >>>> This happened in both interactive and non-interactive mode, however,
> >>>> only on a virtual machine running Vista. On a real computer running
> >>>> Windows 7, startup was instantaneous.
> >>>
> >>> I seem to recall this was discussed a couple of years ago.
> >>> The issue then was that if the program did not find a certain set of fonts,
> >>> it triggered creation of a bitmap font set from the underlying font
> >>> descriptions.  This was painfully slow but only  happened the first time,
> >>> since subsequent runs would find the  now-created font set.
> >>> However, I wonder if you run under a virtual machine whether every time
> >>> is a "first" time?  Anyhow, my best guess is that this is a font issue
> >>> rather than anything to do with gnuplot per se.
> >>>
> >>> 	Ethan
> >>>
> >>
> >> The cairo terminals no longer use the fontconfig mechanism of Windows,
> >> so this particular issue should have been solved.
> >> On the other hand I vaguely remember a similar report a while ago, but I
> >> couldn't reproduce on various XP, Vista and 7 machines.
> >>
> >
> > On further testing I've noticed that there *is* a slight delay on
> > startup even on the Win7 machine (4-5 seconds). This means that even
> > something like 'gnuplot -e "print 1"' takes this much time.
> >
> > Péter Juhász
> >
> 
> Finally, I have been able to reproduce this delay on a Vista machine 
> using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
> 4.5 build which does not include cairo and wxt terminals does not show 
> the delay on start-up.
> Also, I do not see any notable delay using my own build (including wxt 
> and cairo), see
> http://gnuplot.info/development/binaries/
> Is anybody able to reproduce this observation?
> 
>    Bastian


I've fired up that virtual machine that produced that 5 minute delay
earlier. Some observations on several different builds:

gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
(25-Feb-2012 07:19): a small (1-2 s) delay on startup.

gp450win32-small-setup.zip from
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
feebe279501075f8806a04a4029f899c): No delay at all!

gp450win32-setup.zip from the same location (2012-02-23, md5sum
728918c93811f1644711c05fecaebd8f): several minutes of delay.

I thought that if the delay is related to the initialization of the wxt
terminal, then setting the GNUTERM variable to "windows" may alleviate
the problem, but it didn't.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

[Tatsuro M. <tma...@ya...>]

--- On Sat, 2012/2/25, Juhász Péter wrote:

> On Sat, 2012-02-25 at 09:04 +0100, Bastian Märkisch wrote:
> > Am 17.02.2012 19:16, schrieb Juhász Péter:
> > > On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> > >>
> > >> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> > >>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> > >>>>
> > >>>> - On one of my machines, startup appeared to be extremely slow, taking
> > >>>> about 5 minutes (!). This is true for both the console and GUI versions.
> > >>>> For the first few tries I've actually killed the process, because I
> > >>>> didn't have the patience to wait it out. Once it started, it appeared to
> > >>>> work normally, there were no delays and plotting was instantaneous as
> > >>>> well. (Older versions had a long delay at the first plot because of
> > >>>> fontconfig or whatever.)
> > >>>> This happened in both interactive and non-interactive mode, however,
> > >>>> only on a virtual machine running Vista. On a real computer running
> > >>>> Windows 7, startup was instantaneous.
> > >>>
> > >>> I seem to recall this was discussed a couple of years ago.
> > >>> The issue then was that if the program did not find a certain set of fonts,
> > >>> it triggered creation of a bitmap font set from the underlying font
> > >>> descriptions.  This was painfully slow but only  happened the first time,
> > >>> since subsequent runs would find the  now-created font set.
> > >>> However, I wonder if you run under a virtual machine whether every time
> > >>> is a "first" time?  Anyhow, my best guess is that this is a font issue
> > >>> rather than anything to do with gnuplot per se.
> > >>>
> > >>>     Ethan
> > >>>
> > >>
> > >> The cairo terminals no longer use the fontconfig mechanism of Windows,
> > >> so this particular issue should have been solved.
> > >> On the other hand I vaguely remember a similar report a while ago, but I
> > >> couldn't reproduce on various XP, Vista and 7 machines.
> > >>
> > >
> > > On further testing I've noticed that there *is* a slight delay on
> > > startup even on the Win7 machine (4-5 seconds). This means that even
> > > something like 'gnuplot -e "print 1"' takes this much time.
> > >
> > > Péter Juhász
> > >
> > 
> > Finally, I have been able to reproduce this delay on a Vista machine 
> > using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
> > 4.5 build which does not include cairo and wxt terminals does not show 
> > the delay on start-up.
> > Also, I do not see any notable delay using my own build (including wxt 
> > and cairo), see
> > http://gnuplot.info/development/binaries/
> > Is anybody able to reproduce this observation?
> > 
> >    Bastian
> 
> 
> I've fired up that virtual machine that produced that 5 minute delay
> earlier. Some observations on several different builds:
> 
> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> 
> gp450win32-small-setup.zip from
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> feebe279501075f8806a04a4029f899c): No delay at all!
> 
> gp450win32-setup.zip from the same location (2012-02-23, md5sum
> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> 
> I thought that if the delay is related to the initialization of the wxt
> terminal, then setting the GNUTERM variable to "windows" may alleviate
> the problem, but it didn't.
> 
> Péter Juhász
> 
One of the possibility is that the version of wxwidgets.  Now I am using wxwidgets-2.9.3.
To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
Now my condition is not so good, I cannot commit further at the moment.

Sorry for inconvenience.

Tatsuro

Re: Observations on the 4.6rc1 windows package

[Tatsuro M. <tma...@ya...>]

--- On Mon, 2012/2/27, Tatsuro MATSUOKA  wrote:
> --- On Sat, 2012/2/25, Juhász Péter wrote:
> 
> > On Sat, 2012-02-25 at 09:04 +0100, Bastian Märkisch wrote:
> > > Am 17.02.2012 19:16, schrieb Juhász Péter:
> > > > On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> > > >>
> > > >> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> > > >>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> > > >>>>
> > > >>>> - On one of my machines, startup appeared to be extremely slow, taking
> > > >>>> about 5 minutes (!). This is true for both the console and GUI versions.
> > > >>>> For the first few tries I've actually killed the process, because I
> > > >>>> didn't have the patience to wait it out. Once it started, it appeared to
> > > >>>> work normally, there were no delays and plotting was instantaneous as
> > > >>>> well. (Older versions had a long delay at the first plot because of
> > > >>>> fontconfig or whatever.)
> > > >>>> This happened in both interactive and non-interactive mode, however,
> > > >>>> only on a virtual machine running Vista. On a real computer running
> > > >>>> Windows 7, startup was instantaneous.
> > > >>>
> > > >>> I seem to recall this was discussed a couple of years ago.
> > > >>> The issue then was that if the program did not find a certain set of fonts,
> > > >>> it triggered creation of a bitmap font set from the underlying font
> > > >>> descriptions.  This was painfully slow but only  happened the first time,
> > > >>> since subsequent runs would find the  now-created font set.
> > > >>> However, I wonder if you run under a virtual machine whether every time
> > > >>> is a "first" time?  Anyhow, my best guess is that this is a font issue
> > > >>> rather than anything to do with gnuplot per se.
> > > >>>
> > > >>>     Ethan
> > > >>>
> > > >>
> > > >> The cairo terminals no longer use the fontconfig mechanism of Windows,
> > > >> so this particular issue should have been solved.
> > > >> On the other hand I vaguely remember a similar report a while ago, but I
> > > >> couldn't reproduce on various XP, Vista and 7 machines.
> > > >>
> > > >
> > > > On further testing I've noticed that there *is* a slight delay on
> > > > startup even on the Win7 machine (4-5 seconds). This means that even
> > > > something like 'gnuplot -e "print 1"' takes this much time.
> > > >
> > > > Péter Juhász
> > > >
> > > 
> > > Finally, I have been able to reproduce this delay on a Vista machine 
> > > using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
> > > 4.5 build which does not include cairo and wxt terminals does not show 
> > > the delay on start-up.
> > > Also, I do not see any notable delay using my own build (including wxt 
> > > and cairo), see
> > > http://gnuplot.info/development/binaries/
> > > Is anybody able to reproduce this observation?
> > > 
> > >    Bastian
> > 
> > 
> > I've fired up that virtual machine that produced that 5 minute delay
> > earlier. Some observations on several different builds:
> > 
> > gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> > (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> > 
> > gp450win32-small-setup.zip from
> > http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> > feebe279501075f8806a04a4029f899c): No delay at all!
> > 
> > gp450win32-setup.zip from the same location (2012-02-23, md5sum
> > 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> > 
> > I thought that if the delay is related to the initialization of the wxt
> > terminal, then setting the GNUTERM variable to "windows" may alleviate
> > the problem, but it didn't.
> > 
> > Péter Juhász
> > 
> One of the possibility is that the version of wxwidgets.  Now I am using wxwidgets-2.9.3.
> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
> Now my condition is not so good, I cannot commit further at the moment.
> 
> Sorry for inconvenience.
> 
> Tatsuro
> 

Hello

I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the recent cvs source.
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
gp450win32-setup.zip

Please test this binary shows slow startup or not.

Regards

Tatsuro

Re: Observations on the 4.6rc1 windows package

[Bastian M. <bma...@we...>]

>>> I've fired up that virtual machine that produced that 5 minute delay
>>> earlier. Some observations on several different builds:
>>>
>>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
>>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
>>>
>>> gp450win32-small-setup.zip from
>>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
>>> feebe279501075f8806a04a4029f899c): No delay at all!
>>>
>>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
>>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
>>>
>>> I thought that if the delay is related to the initialization of the wxt
>>> terminal, then setting the GNUTERM variable to "windows" may alleviate
>>> the problem, but it didn't.
>>>
>>> Péter Juhász
>>>
>> One of the possibility is that the version of wxwidgets.  Now I am using wxwidgets-2.9.3.
>> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
>> Now my condition is not so good, I cannot commit further at the moment.
>>
>> Sorry for inconvenience.
>>
>> Tatsuro
>>
>
> Hello
>
> I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the recent cvs source.
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> gp450win32-setup.zip
>
> Please test this binary shows slow startup or not.
>
> Regards
>
> Tatsuro
>

Thanks for providing a new build so quickly! On my Vista machine your 
(old) build with wxWidgets 2.9.3 takes ~6s to start up, whereas the 
build with wxWidgets 2.8.12 takes only 0.7s. This is exactly the same 
time it takes for my own build to start up (wxWidgets 2.8.11).
For the moment, I would thus suggest to stay with 2.8 for a 4.6 release 
build.

   Bastian

Re: Observations on the 4.6rc1 windows package

[Tatsuro M. <tma...@ya...>]

--- On Mon, 2012/2/27, Bastian Märkisch wrote:
> >>> I've fired up that virtual machine that produced that 5 minute delay
> >>> earlier. Some observations on several different builds:
> >>>
> >>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> >>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> >>>
> >>> gp450win32-small-setup.zip from
> >>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> >>> feebe279501075f8806a04a4029f899c): No delay at all!
> >>>
> >>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
> >>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> >>>
> >>> I thought that if the delay is related to the initialization of the wxt
> >>> terminal, then setting the GNUTERM variable to "windows" may alleviate
> >>> the problem, but it didn't.
> >>>
> >>> Péter Juhász
> >>>
> >> One of the possibility is that the version of wxwidgets.  Now I am using wxwidgets-2.9.3.
> >> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
> >> Now my condition is not so good, I cannot commit further at the moment.
> >>
> >> Sorry for inconvenience.
> >>
> >> Tatsuro
> >>
> >
> > Hello
> >
> > I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the recent cvs source.
> > http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> > gp450win32-setup.zip
> >
> > Please test this binary shows slow startup or not.
> >
> > Regards
> >
> > Tatsuro
> >
> 
> Thanks for providing a new build so quickly! On my Vista machine your 
> (old) build with wxWidgets 2.9.3 takes ~6s to start up, whereas the 
> build with wxWidgets 2.8.12 takes only 0.7s. This is exactly the same 
> time it takes for my own build to start up (wxWidgets 2.8.11).
> For the moment, I would thus suggest to stay with 2.8 for a 4.6 release 
> build.
> 
>    Bastian

Hello

Thank you for immediate test.  I will use wxWidgets 2.8.12 for the moment.

Thank you for all who found and commit the slowness issue. 

Regards

Tatsuro
 

Re: Observations on the 4.6rc1 windows package

[Peter J. <pet...@gm...>]

2012/2/27 Bastian Märkisch <bma...@we...>:
>>>> I've fired up that virtual machine that produced that 5 minute delay
>>>> earlier. Some observations on several different builds:
>>>>
>>>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
>>>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
>>>>
>>>> gp450win32-small-setup.zip from
>>>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
>>>> feebe279501075f8806a04a4029f899c): No delay at all!
>>>>
>>>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
>>>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
>>>>
>>>> I thought that if the delay is related to the initialization of the wxt
>>>> terminal, then setting the GNUTERM variable to "windows" may alleviate
>>>> the problem, but it didn't.
>>>>
>>>> Péter Juhász
>>>>
>>> One of the possibility is that the version of wxwidgets.  Now I am using
>>> wxwidgets-2.9.3.
>>> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
>>> Now my condition is not so good, I cannot commit further at the moment.
>>>
>>> Sorry for inconvenience.
>>>
>>> Tatsuro
>>>
>>
>> Hello
>>
>> I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the
>> recent cvs source.
>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
>> gp450win32-setup.zip
>>
>> Please test this binary shows slow startup or not.
>>
>> Regards
>>
>> Tatsuro
>>
>
> Thanks for providing a new build so quickly! On my Vista machine your (old)
> build with wxWidgets 2.9.3 takes ~6s to start up, whereas the build with
> wxWidgets 2.8.12 takes only 0.7s. This is exactly the same time it takes for
> my own build to start up (wxWidgets 2.8.11).
> For the moment, I would thus suggest to stay with 2.8 for a 4.6 release
> build.
>
>  Bastian

I confirm the speedup with this new build: on this pathological Vista
virtual machine I have the delay on startup has shrunk down to 8
seconds. On a real XP box the delay is less than 1 s.

Perhaps it would be illuminating to look at the changelogs of
wxWidgets to see what could possibly cause this effect, and also test
whether it appears on non-Windows platforms.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

[Ethan A M. <sf...@us...>]

On Monday, February 27, 2012 02:44:22 am Peter Juhasz wrote:
> 2012/2/27 Bastian M�rkisch <bma...@we...>:
> >>>> I've fired up that virtual machine that produced that 5 minute delay
> >>>> earlier. Some observations on several different builds:
> >>>>
> >>>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> >>>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> >>>>
> >>>> gp450win32-small-setup.zip from
> >>>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> >>>> feebe279501075f8806a04a4029f899c): No delay at all!
> >>>>
> >>>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
> >>>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> >>>>
> >>>> I thought that if the delay is related to the initialization of the wxt
> >>>> terminal, then setting the GNUTERM variable to "windows" may alleviate
> >>>> the problem, but it didn't.
> >>>>
> >>>> P�ter Juh�sz
> >>>>
> >>> One of the possibility is that the version of wxwidgets. �Now I am using
> >>> wxwidgets-2.9.3.
> >>> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
> >>> Now my condition is not so good, I cannot commit further at the moment.
> >>>
> >>> Sorry for inconvenience.
> >>>
> >>> Tatsuro
> >>>
> >>
> >> Hello
> >>
> >> I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the
> >> recent cvs source.
> >> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> >> gp450win32-setup.zip
> >>
> >> Please test this binary shows slow startup or not.
> >>
> >> Regards
> >>
> >> Tatsuro
> >>
> >
> > Thanks for providing a new build so quickly! On my Vista machine your (old)
> > build with wxWidgets 2.9.3 takes ~6s to start up, whereas the build with
> > wxWidgets 2.8.12 takes only 0.7s. This is exactly the same time it takes for
> > my own build to start up (wxWidgets 2.8.11).
> > For the moment, I would thus suggest to stay with 2.8 for a 4.6 release
> > build.
> >
> > �Bastian
> 
> I confirm the speedup with this new build: on this pathological Vista
> virtual machine I have the delay on startup has shrunk down to 8
> seconds. On a real XP box the delay is less than 1 s.
> 
> Perhaps it would be illuminating to look at the changelogs of
> wxWidgets to see what could possibly cause this effect, and also test
> whether it appears on non-Windows platforms.
> 
> P�ter Juh�sz

This tracker:
  http://openeuphoria.org/forum/117422.wc
suggests that it can take 15 seconds to load the 2.9 wxWidgets *.dll if it is
built as a monolithic library. Splitting it into smaller pieces may help.

And this one:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
gives work-arounds for horrible problems when compiling wxWidgets with certain 
versions of Mingw and gcc

I gather from the wxWiki pages that the package can be built in either
"debug" or "release" mode.  The latter can be much faster.  Several debug levels
are possible.   Apparently the defaults changed between 2.8 and 2.9, so maybe
this is part of the problem? 


	Ethan

Re: Observations on the 4.6rc1 windows package

[Tatsuro M. <tma...@ya...>]

--- On Tue, 2012/2/28, Ethan A Merritt  wrote:
> On Monday, February 27, 2012 02:44:22 am Peter Juhasz wrote:
> > 2012/2/27 Bastian M�rkisch <bma...@we...>:
> > >>>> I've fired up that virtual machine that produced that 5 minute delay
> > >>>> earlier. Some observations on several different builds:
> > >>>>
> > >>>> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> > >>>> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> > >>>>
> > >>>> gp450win32-small-setup.zip from
> > >>>> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> > >>>> feebe279501075f8806a04a4029f899c): No delay at all!
> > >>>>
> > >>>> gp450win32-setup.zip from the same location (2012-02-23, md5sum
> > >>>> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> > >>>>
> > >>>> I thought that if the delay is related to the initialization of the wxt
> > >>>> terminal, then setting the GNUTERM variable to "windows" may alleviate
> > >>>> the problem, but it didn't.
> > >>>>
> > >>>> P�ter Juh�sz
> > >>>>
> > >>> One of the possibility is that the version of wxwidgets. �Now I am using
> > >>> wxwidgets-2.9.3.
> > >>> To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
> > >>> Now my condition is not so good, I cannot commit further at the moment.
> > >>>
> > >>> Sorry for inconvenience.
> > >>>
> > >>> Tatsuro
> > >>>
> > >>
> > >> Hello
> > >>
> > >> I have downgraded wxWidgets from version 2.9.3 to 2.8.12 and built the
> > >> recent cvs source.
> > >> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> > >> gp450win32-setup.zip
> > >>
> > >> Please test this binary shows slow startup or not.
> > >>
> > >> Regards
> > >>
> > >> Tatsuro
> > >>
> > >
> > > Thanks for providing a new build so quickly! On my Vista machine your (old)
> > > build with wxWidgets 2.9.3 takes ~6s to start up, whereas the build with
> > > wxWidgets 2.8.12 takes only 0.7s. This is exactly the same time it takes for
> > > my own build to start up (wxWidgets 2.8.11).
> > > For the moment, I would thus suggest to stay with 2.8 for a 4.6 release
> > > build.
> > >
> > > �Bastian
> > 
> > I confirm the speedup with this new build: on this pathological Vista
> > virtual machine I have the delay on startup has shrunk down to 8
> > seconds. On a real XP box the delay is less than 1 s.
> > 
> > Perhaps it would be illuminating to look at the changelogs of
> > wxWidgets to see what could possibly cause this effect, and also test
> > whether it appears on non-Windows platforms.
> > 
> > P�ter Juh�sz
> 
> This tracker:
>   http://openeuphoria.org/forum/117422.wc
> suggests that it can take 15 seconds to load the 2.9 wxWidgets *.dll if it is
> built as a monolithic library. Splitting it into smaller pieces may help.
> 
> And this one:
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
> gives work-arounds for horrible problems when compiling wxWidgets with certain 
> versions of Mingw and gcc
> 
> I gather from the wxWiki pages that the package can be built in either
> "debug" or "release" mode.  The latter can be much faster.  Several debug levels
> are possible.   Apparently the defaults changed between 2.8 and 2.9, so maybe
> this is part of the problem? 
> 
> 
>     Ethan

Hello

> This tracker:
>   http://openeuphoria.org/forum/117422.wc
> suggests that it can take 15 seconds to load the 2.9 wxWidgets *.dll if it is
> built as a monolithic library. Splitting it into smaller pieces may help.

Perhaps I made smaller pieces dll libraries. 

>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
> gives work-arounds for horrible problems when compiling wxWidgets with certain 
> versions of Mingw and gcc

I have noticed this one. I have attached the patch when building wxWidgets 2.8 in order to avoid increase in size of the dll files.

Anyway thank you for your pointer.

Regards

Tatsuro

Re: Observations on the 4.6rc1 windows package

[<pl...@pi...>]

On 02/27/12 11:44, Peter Juhasz wrote:
> Perhaps it would be illuminating to look at the changelogs of
> wxWidgets to see what could possibly cause this effect, and also test
> whether it appears on non-Windows platforms.

using recent CVS and wxGTK-2.8.12.1 , not unusual slowness.

Re: Observations on the 4.6rc1 windows package

[Peter J. <pet...@gm...>]

On Mon, Feb 27, 2012 at 1:31 PM,  <pl...@pi...> wrote:
> On 02/27/12 11:44, Peter Juhasz wrote:
>> Perhaps it would be illuminating to look at the changelogs of
>> wxWidgets to see what could possibly cause this effect, and also test
>> whether it appears on non-Windows platforms.
>
> using recent CVS and wxGTK-2.8.12.1 , not unusual slowness.
>

Same for me, but it'd be interesting to upgrade wx* to 2.9.3 and
retry, as the problems on windows appeared with that version.

Péter Juhász

Re: Observations on the 4.6rc1 windows package

[<pl...@pi...>]

On 02/27/12 16:43, Peter Juhasz wrote:
> On Mon, Feb 27, 2012 at 1:31 PM,<pl...@pi...>  wrote:
>> On 02/27/12 11:44, Peter Juhasz wrote:
>>> Perhaps it would be illuminating to look at the changelogs of
>>> wxWidgets to see what could possibly cause this effect, and also test
>>> whether it appears on non-Windows platforms.
>>
>> using recent CVS and wxGTK-2.8.12.1 , not unusual slowness.
>>
>
> Same for me, but it'd be interesting to upgrade wx* to 2.9.3 and
> retry, as the problems on windows appeared with that version.
>
> Péter Juhász
>

sorry , not paying attention.

Gentoo throws this msg if I try to force that version.

# Ryan Hill <dir...@ge...> (22 Jan 2011)
# Mask development versions due to unstable API
# as requested by leio
=x11-libs/wxGTK-2.9.1.1

I don't have much interest in screwing half my system and not getting 
other things done while trying to patch it up again.

I already run "testing" profile, if this is not even in testing I guess 
they know it really is still buggy still.

Peter.

Re: Observations on the 4.6rc1 windows package

[Ethan A M. <sf...@us...>]

On Monday, February 27, 2012 09:00:37 am pl...@pi... wrote:
> On 02/27/12 16:43, Peter Juhasz wrote:
> > On Mon, Feb 27, 2012 at 1:31 PM,<pl...@pi...>  wrote:
> >> On 02/27/12 11:44, Peter Juhasz wrote:
> >>> Perhaps it would be illuminating to look at the changelogs of
> >>> wxWidgets to see what could possibly cause this effect, and also test
> >>> whether it appears on non-Windows platforms.
> >>
> >> using recent CVS and wxGTK-2.8.12.1 , not unusual slowness.
> >>
> >
> > Same for me, but it'd be interesting to upgrade wx* to 2.9.3 and
> > retry, as the problems on windows appeared with that version.
> >
> > P�ter Juh�sz
> >
> 
> sorry , not paying attention.
> 
> Gentoo throws this msg if I try to force that version.
> 
> # Ryan Hill <dir...@ge...> (22 Jan 2011)
> # Mask development versions due to unstable API
> # as requested by leio
> =x11-libs/wxGTK-2.9.1.1
> 
> I don't have much interest in screwing half my system and not getting 
> other things done while trying to patch it up again.
> 
> I already run "testing" profile, if this is not even in testing I guess 
> they know it really is still buggy still.
> 
> Peter.

Mojca Miklavec reported earlier that wxWidgets 2.9 has problems on OSX.

> from: Mojca Miklavec 01-Aug-2011
> > Anyhow, I take it the bottom line is that wxWidgets 2.8 does work,
> > but 2.9 does not?
> 
> True. I'm not sure what is wrong with 2.9, but it might also be a bug
> in their code, not just the need to rewrite the program. It would make
> a lot of sense to resolve such bugs before 3.0 is released, but I
> don't know how to create a minimal example to submit a bug report (if
> there is one).

The wxWidgets project documentation warns that 2.9 and 2.8 are not
100% compatible, although the only specific relevant examples that I
see there have to do with unicode characters and with wxString objects
in general.

Re: Observations on the 4.6rc1 windows package

[Mojca M. <moj...@gm...>]

On Mon, Feb 27, 2012 at 12:22, Ethan A Merritt wrote:
>
> Mojca Miklavec reported earlier that wxWidgets 2.9 has problems on OSX.

However it works now - after some patches have been applied to gnuplot
(or maybe I should double check that the patches are indeed in sources
and not just on my computer).


Before claiming differences in startup speed, please double check
something that definitely has a huge influence. I think that wxWidgets
use fc-config and when one first starts the program, it will always
take a considerable amount of time to build font caches (it has to
scan all fonts in C:\Windows\Fonts and possibly some others). So it
might be that whenever one tested the new build with wxt 2.9, it was
only rebuilding caches and the second run would be faster, while the
caches for gnuplot with wxt 2.8 were already present and thus gnuplot
start was faster. This problem should not occur on linux and mac and
you cannot get rid of it on windows unless you rewrite some code from
wxt or configure fontconfig in a different way (but then users might
just as well start complaining that the new fonts don't work in
gnuplot).

Mojca

Re: Observations on the 4.6rc1 windows package

[Bastian M. <bma...@we...>]

Am 27.02.2012 20:35, schrieb Mojca Miklavec:
> On Mon, Feb 27, 2012 at 12:22, Ethan A Merritt wrote:
>>
>> Mojca Miklavec reported earlier that wxWidgets 2.9 has problems on OSX.
>
> However it works now - after some patches have been applied to gnuplot
> (or maybe I should double check that the patches are indeed in sources
> and not just on my computer).
>
>
> Before claiming differences in startup speed, please double check
> something that definitely has a huge influence. I think that wxWidgets
> use fc-config and when one first starts the program, it will always
> take a considerable amount of time to build font caches (it has to
> scan all fonts in C:\Windows\Fonts and possibly some others). So it
> might be that whenever one tested the new build with wxt 2.9, it was
> only rebuilding caches and the second run would be faster, while the
> caches for gnuplot with wxt 2.8 were already present and thus gnuplot
> start was faster. This problem should not occur on linux and mac and
> you cannot get rid of it on windows unless you rewrite some code from
> wxt or configure fontconfig in a different way (but then users might
> just as well start complaining that the new fonts don't work in
> gnuplot).
>
> Mojca

Tests have been run several times of course. Please note that the 
cairo/pango terminals (including wxt) no longer use the fontconfig 
mechanism.

   Bastian

Re: Observations on the 4.6rc1 windows package

[Juhász P. <pet...@gm...>]

On Mon, 2012-02-27 at 20:53 +0100, Bastian Märkisch wrote:
> 
> Am 27.02.2012 20:35, schrieb Mojca Miklavec:
> > On Mon, Feb 27, 2012 at 12:22, Ethan A Merritt wrote:
> >>
> >> Mojca Miklavec reported earlier that wxWidgets 2.9 has problems on OSX.
> >
> > However it works now - after some patches have been applied to gnuplot
> > (or maybe I should double check that the patches are indeed in sources
> > and not just on my computer).
> >
> >
> > Before claiming differences in startup speed, please double check
> > something that definitely has a huge influence. I think that wxWidgets
> > use fc-config and when one first starts the program, it will always
> > take a considerable amount of time to build font caches (it has to
> > scan all fonts in C:\Windows\Fonts and possibly some others). So it
> > might be that whenever one tested the new build with wxt 2.9, it was
> > only rebuilding caches and the second run would be faster, while the
> > caches for gnuplot with wxt 2.8 were already present and thus gnuplot
> > start was faster. This problem should not occur on linux and mac and
> > you cannot get rid of it on windows unless you rewrite some code from
> > wxt or configure fontconfig in a different way (but then users might
> > just as well start complaining that the new fonts don't work in
> > gnuplot).
> >
> > Mojca
> 
> Tests have been run several times of course. Please note that the 
> cairo/pango terminals (including wxt) no longer use the fontconfig 
> mechanism.
> 
>    Bastian
> 

I remember that there used to be delays related to font caching but this
issue seems to be something else. For one, that delay used to manifest
itself the first time I used the wxt terminal, and only then. This delay
shows up every time I start the program, even in non-interactive mode.
And as Bastian says, the fontconfig mechanism is not used anymore.

Péter Juhász