Change default value of Generic/AutoSaveFrequency from 30 seconds to 5

[davelab6]

The AutoSaveFrequency is 30 seconds, and a lot can change in 30 seconds, so change it to 5 seconds so that very little work is lost.

[ghost]

Is it really 30 seconds? That seems much too frequent, and 5 seconds that much worse. I always thought the number in the dialog was in units of minutes. Other programs that have an autosave feature, such as word processors, usually default to about 10 minutes. Extremely frequent autosave will have undesirable effects on systems that spin down hard drives to save power, such as laptops.

[ultrasquid]

Such frequent autosaves would make the revert to previous save features
nearly useless, would they not?

On Mon, Mar 11, 2013 at 12:33 PM, Matthew Skala notifications@github.comwrote:

Is it really 30 seconds? That seems much too frequent, and 5 seconds that
much worse. I always thought the number in the dialog was in units of
minutes. Other programs that have an autosave feature, such as word
processors, usually default to about 10 minutes. Extremely frequent
autosave will have undesirable effects on systems that spin down hard
drives to save power, such as laptops.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/410#issuecomment-14736881
.

Jason Pagura
zimbach at gmail dot com

[vernnobile]

Are we talking about the frequency that fontforge saves a backup sfd file?
A much more succinct approach imo would be something similiar to what other apps do (like photoshop etc), where every edit action is recorded in cache, and the user can step back to whatever edit they need to, via a gui palette. I forgot what the function is called, 'history' rings a bell.
Autosaving back up files would be separate, and as Mathew points out would ideally be less frequent.

-v

On 11 Mar 2013, at 12:33, Matthew Skala notifications@github.com wrote:

Is it really 30 seconds? That seems much too frequent, and 5 seconds that much worse. I always thought the number in the dialog was in units of minutes. Other programs that have an autosave feature, such as word processors, usually default to about 10 minutes. Extremely frequent autosave will have undesirable effects on systems that spin down hard drives to save power, such as laptops.

—
Reply to this email directly or view it on GitHub.

[davelab6]

@mskala Yes, that's what the tooltip says - - and I think losing some battery time is much preferable to losing work, since the experience of a program losing your work makes you hate the program and not want to use it. Since these are preferences, if you prefer it to be much longer, you can do so.

@vernnobile No, we are talking about the ~/.FontForge/autosave/Font-Style.asfd files that are saved in a constantly operating loop in the background, without any user action; I think you are referring to 'Saved Revisions' which is something I asked Ben to implement recently?

I agree that UndoRedo actions should have a palette to browse them, please mock that up and file it as a separate issue :)

[davelab6]

I've filed #414 which is related to this issue

[monkeyiq]

#416

[monkeyiq]

verified in 201303/12_1745

[davelab6]

@ultrasquid the Revert feature reloads the file as saved from disk, not from the autosave - the autosave is only for crash recovery.

@mskala I've added this to #337 so users will be advised that the autosave is 5s, and this may effect battery life on a laptop, so they can change the value of this as needed :)

[davelab6]

@mskala upon reflection, I think maybe the 5s value should be in the First Run Wizard. What do you think the value SHOULD be by default? 5 mins?

[ghost]

I have a few thoughts.

1. I don't consider this a high-priority issue. I mentioned the laptop power consumption thing because I thought commentators here might not think of it, and might not see any disadvantages at all to making the time delay as short as possible (why not 1 second instead of 5?). But the existing 30 seconds, which I think is already very frequent indeed and notably much more often than what other software does, hasn't actually caused any real problems I'm aware of. My suggestion that laptop users might have a reason to not like it is hypothetical. I'd much rather save my energy, and my limited ability to influence others, for issues like "Remove overlaps" and "find intersections" delete points at 90-degree corners, creating large black areas in glyphs #402 . Somebody - just maybe not me - legitimately wants 5-second saves, and if I don't, then I can change my configuration. So if it becomes 5 seconds, I've mentioned here that I'm not sure that's a good idea, but I don't really care. On the other hand, nobody benefits from incorrect results in Remove Overlaps, and I can't fix that for myself just by changing my config. That's a real problem.

2. I've said it before, but: we seem to have an awful lot of issues filed that are of the form "Change the default value of..." and I think such issues tend to be accepted and implemented more eagerly than is a good idea. Changing a default is a big deal because it is guaranteed to create unpleasant surprises for existing users who were using the existing default and didn't know they were doing so; it comes across as "the development team broke the software in order to make things nicer for someone other than me"; and I think the amount of thought the FontForge development team usually applies to proposed changes of defaults before implementing them, isn't the ideal amount of thought.

3. I think having a First Run Wizard is a UI gaffe. When I see that an application has one, I perceive it as meaning one of a few things: A. "We think our users are so stupid they need to be told things like 'The File menu provides commands related to files (such as Exit, which isn't)' before they can be allowed to touch the software, or in the case of 'tips,' every time they try to use the software." B. "We know our defaults are bad, so we have to give users a chance to fix them right up front." C. "We have an incorrect data model, such as assuming that the user has exactly one email account." (Vining's Oversight) D. "We're going to dump many megabytes of garbage into a hidden folder in the user's home directory." or E. "We want to override the configuration of other software or the system as a whole (for instance, by making ourselves the default browser), and antitrust law, or the fear of it, requires us to go through a user interaction before doing so." FontForge seems to fall mostly into category B here, possibly edging into D once all the automatic backups are up to speed. (Really, I wonder if some of your workshop users have blocks of stock in hard disk manufacturers for all the disk-consuming features they request.) However, just like point 1 above, I don't think this is important, and I wouldn't have mentioned it except that I'm writing a long reply now anyway. Fine, go ahead and create a First Run Wizard; there are probably users who will benefit from it and it's not really any skin off my nose. If you want to discuss it further, Add a First Run Wizard #337 may be a better place to do so than here.

4. I don't understand what the current auto-save algorithm actually is, and that makes a difference to what's a good time interval. I can think of several possibilities.

   1. It really saves every X seconds, unconditionally.
   2. Every X seconds it checks whether there are unsaved changes, and saves if and only if the answer is "yes."
   3. It saves whenever there are unsaved changes and it has been at least X seconds since the last save.
   4. It saves whenever there are unsaved changes and it has been at least Y seconds since the last change.
   5. It saves whenever there are unsaved changes and EITHER it has been at least X seconds since the last save, OR it has been at least Y seconds since the last change.

   If we're currently following method 1, I think X should be at least five minutes by default. Methods 2 and 3 are very similar; with either of them I think I would set it to no less than 30 seconds by default, but 30 seconds isn't a disaster and even 5 could be reasonable. I think the laptop power thing is only a problem if it repeatedly spins up the hard drive at frequent intervals while sitting idle; keeping it spun up during active use isn't a big deal. Method 4 could cause problems because it means that someone who keeps making changes frequently will never get a save at all - in such a case I think it should be no more than 30 seconds because otherwise there will be very few saves. Method 5 is the one I like best but also the most complicated, and it's probably not what we're doing right now (requiring more work to implement) because we have only one config setting. I think the defaults I would choose for that would be X=900 (that is 15 minutes), Y=30, but many other settings would be reasonable. Laptop users who are really worried about their power might prefer a much larger value of Y.

But I emphasize that nobody has complained about the existing 30-second setting, and that's already short enough that reducing it to 5 probably won't increase any existing hard-drive spin-up issues.

[davelab6]

(Reopening this so I am sure to write you back a considered response :)

[mozbugbox]

How about save snapshot in memory every 5 secs and dump to disk every 30 mins. Also catch the segfault signal so that memory snapshot can be dumped to disk on crash.

30 mins backup is practically useless.

[ghost]

Saving snapshots to memory seems like it would duplicate the effect of the existing undo feature, which is like having a snapshot instantly after every change. I think in order to provide additional protection beyond what "undo" provides, regular backups must to be written to disk. As for catching segfaults, see http://thecodelesscode.com/case/60 .

[davelab6]

On 13 March 2013 00:26, mozbugbox notifications@github.com wrote:

How about save snapshot in memory every 5 secs and dump to disk every 30
mins.

This feature is about crash protection; so a snapshot in memory every 5
seconds will be lost when FF crashes.

Also catch the segfault signal so that memory snapshot can be dumped to

disk on crash.

You mean integrating the BreakPad crash reporter?

[ghost]

Operating systems already have a feature for dumping a memory snapshot to disk when a crash occurs. It's called core dump, and it hasn't been popular in decades, but it still exists as an option (at least in Linux) and it doesn't require any application support. Core dump can be enabled with the ulimit command (for anything, not just FontForge) and may be useful for debugging. It doesn't allow you to start up again and pick up from where you were before the segfault, but I don't see how we could build one that would allow such a thing... if the process could continue, there wouldn't be a segfault.

[mozbugbox]

What I meant was to snapshot the .sfd data to the memory instead of the hard drive. And dump that data to hard drive in case of crash. You can also CRC the data if you are worrying about data corruption.

[davelab6]

On the list @mskala wrote:

On Wed, 13 Mar 2013, Dave Crossland wrote:

people lose their work from a crash. The reason for 5 seconds is that
this value means people can only lose 5 seconds worth of work when FF
crashes. At 30 seconds, enough work can be lost that it is annoying.
At 1 minute+, so much work can be lost that I will forget exactly what
shape I had drawn.

It seems to me that if we would consider 5 seconds, then there's not much
point having a delay at all. Why not save immediately after every
editing operation? And that may, indeed, be the right answer as an
option.

I am curious the reasons why you think a much longer period is more
useful - I understand the effect of HD spin up on battery life. Are
there more general reasons?

I had a script that called Save() after every cut and paste operation
between two files, because at the time I incorrectly thought that I needed
to do that before calling Open() on the other file. Open() actually just
switches between already-loaded files without discarding the previous one,
so calling Save() every time wasn't necessary. The unnecessay Save()
calls were causing extremely high loads on my RAID, to the point that they
triggered a hardware issue that caused otherwise-good drives to be marked
"failed" and removed from the array. This was a complicated situation
unique to me, and FontForge wasn't the only cause... but it does suggest
that saving large files all the time, every time may not be desirable
for all users. I think "auto-save a backup immediately after every
editing operation" would still be a reasonable thing to do for many users,
though. I don't think a 5-second interval makes much sense. Who is
worried about the possibility of losing 5 seconds of work, and yet is
still okay with losing any work at all?

My favourite option remains the one I describe in my comment on issue
#410: save a short time after the last edit, or a longer time after the
last save, whichever is earlier. That way you don't get your intense,
concentrated runs of human editing interrupted by saves very much, but
after you get to the end of such a run, you get a save very quickly.

Do we really think that purely random unpredictable crashes are all that
common? That's the threat model that time-based saving is designed to
protect against. I think, instead, that we have a pretty good idea of
where crashes are likely to happen, and if we can't expect to fix the
crashes, maybe what we really should do is save immediately before any
dangerous operation that's likely to crash. That's what I do manually, as
a user; and if it's limited to operations that take a relatively long time
to execute, then the time taken to do the save won't be noticed as an
intrusion on the program's response time.

I don't want to wait the time it takes to write the entire font to disk
every time I move a point, but if editing operations were saved as a
journal instead of saving the entire font every time, with the journal
possibly even being buffered and written in a background thread, then it
would be possible to make the system save every single edit to disk
immediately and still not slow down the user perceptibly nor kill the
disks. It's not a large step from having undo/redo to having journalling.

[davelab6]

"save a short time after the last edit, or a longer time after the last save, whichever is earlier" sounds good to me