Re: Help with saveas and fltk

[Nicholas Jankowski]

On Thu, Jun 6, 2013 at 6:25 PM, Rick M. Cox <address@hidden> wrote:

Rick, would help if I could try to reproduce what you're doing. I'm not running XP, but Win7, so things might be different. The "D:/Programs" problem pops up A LOT due to microsoft's infinite wisdom of making core folders with spaces in the filename's. Not just with Octave, either. Previously conversations I've seen with that problem were with configuring editors, though.

If you could upload some simple m-files recreating your problem, I'd be curious to see if it occurs here. Or maybe someone else with an XP box can try recreating the issue.

nickj

 

 

 

Nick:

 

Thanks for the help offer.  I have attached the short Octave program that is an example of my problem.

 

My system:

·       Pentium 4, 3.2 GHz

·       Windows XP Pro SP3

·       Visual C++ 2010 Redistributable Package

·       Octave 3.6.4

·       Latest version of GhostScript

 

Both Octave and GhostScript are installed in paths that have no white spaces.

 

Octave commands:

>scdraw

>print “test.png”

 

With ‘gnuplot’ everything works as expected.  It takes 60 seconds for ‘scdraw’ to generate the Smith Chart and another 50 seconds for the print command to save the file.  I can save any file format without problems.

 

With ‘fltk’ the ‘scdraw’ program generates the Smith Chart in about 10 seconds.  The print command causes the figure window to become scrambled and unresponsive.  Octave is also unresponsive and I have to close it.  Any file format that I try produces the same result.

 

I hope you can help me out!

 

Rick

 

Will check it out when I'm back at work. But FYI i'm running the MinGW version on Win7, so who knows what will happen :)

regarding load time, I do notice when I do other simple things in Octave it takes a long time for the first figure to load (i usually have things set to fltk). so something as simple as:

plot([1 2 3])

will take a long time to run once, but a 'close all' followed by plot([1 2 3]) again will pop right up (same with any other figures after the first). so i assume that the first figure has some program loading or initialization occurring. perhaps something similar here? or is it just as slow every time?