[Joel]

Well, we finished up the remaining compatibility issues with Mac OS X 10.5, most importantly the bug where exporting to PDF could lead to creating a folder that the Finder thought was a Graffle file, and possibly overwriting the originating document.

Other notable fixes include the return of folder import and those folks using Subversion should have an easier time with Graffle documents saved out as file packages.

Full release notes and the beta download can be found at the OmniGraffle beta page.

[Joel]

I would start by quitting OmniGraffle, and manually setting aside or deleting your OmniGraffle preferences (located at ~/Library/Preferences/com.omnigroup.OmniGraffle.plist where ~ is your Home Folder) and see if that makes any difference. If it doesn't, please let me know.

[coffeeguy251]

Thanks, Joel.

Trying that now. I'll let you know.

[Joel]

Also, I'd encourage you to send feedback to omnigraffle@omnigroup.com, I'll be able to help out a lot better that way.

[coffeeguy251]

(Reposted after mistakenly deleting; this post is now out of order...)

OG4.2.2b2 on iBook G4 with Leopard, 1.2GHz, 1.25GB RAM:

Performance is unusably slow, and every 5 minutes like clockwork, the app will peg my CPU and freeze with the spinning beachball of diversity for another solid 5 minutes (I've timed it.) I can't get any work done.

I tried 4.2.1, and it's even worse.

Please do something about this ASAP.

Thank you.

[coffeeguy251]

No change. I'm running MenuMeters, so I can see things like network throughput, CPU usage, RAM usage and disk activity. While OGP4.2.2.b2 is paused, the CPU is pegged (as I said,) and I can see the RAM usage fluctuate wildly, usually filling up completely, with a ton of write disk activity, and then RAM clearing out right before the app becomes responsive again.

BTW, this behavior isn't isolated to this iBook G4. It also happens on a dual 2.3GHz Power Mac G5 with 4.5GB RAM, fresh install of Leopard from a bare disk, and no previous preferences.

[coffeeguy251]

One thing I forgot: this "pausing" behavior will happen if OGP4.2.2b2 is just sitting open with no other apps open, and no activity going on within the app.

[Joel]

I thinking this might have to do with a specific file or files, and what might be contained within them.

Can you send feedback to the email address above so we can take this to the next level?

[coffeeguy251]

Just a quick note to let you know that I've found a workaround.

Fortunately, I had exported Visio XML files of all my .graffle files before moving to Leopard. I opened one of these up in OGP4.2.2b2, and saved it back as a native .graffle file. It's now 2.8MB, which is more like what I expect. I've been working with it, and the size seems to be holding steady, not growing out of control.

FYI, I looked at the contents of the 68MB version of the file (same visual content,) and the data.plist file is almost 67MB, the rest taken up by bitmapped gfx I have embedded in the file. The 2.8MB version of the file has a data.plist inside that's only 40KB.

The odd thing is that the original .graffle file I started with was still only 2.8MB, and had been generated in OGP4.2.1 under Tiger 10.4.10. I didn't do anything strange or weird to the file. I just backed up, installed Leopard on a blank drive, reinstalled apps (including OGP4.2.2b2,) and manually copied all of my files back over from backup. That's when the weirdness started.

Things are humming along nice and quick now. But it's really odd that the two files I opened in 4.2.2b2 grew to uncontrollable sizes. The other file that grew started out at 1.3MB, and after editing in OGP4.2.2b2, grew to 42.1MB.

I'm going to continue working from copies of my Visio XML files until OGP4.2.2 is finalized, and this bug is hopefully found and fixed.

Thanks, Joel, for your help and insights.

[coffeeguy251]

OK, FYI: The problem starts when I try to change the fill color of vector elements embedded within a group. Hopefully that helps.

Now I have to start over from my Visio XML file, and not change colors. =(