Macbook Pro OSX 10.5.3

When entering the menu bar in the File tab. 136 is giving a significant
response delay in opening up the menu items. 137 is giving a very long
delay with a spinning colorwheel before displaying up the File menu. When
entering Sketchbook or Examples again these delays occur.
The delay is not there when entering the other menu tabs. And of course
it's not there when running 135.

hm, that's an apple java issue. will need to see if there's a way to avoid it.

actually, can you try doing "show package contents" on Processing.app, and
then edit the Info.plist where it says "1.5+" for the version, and change
it to "1.5*". if so, it might be a java 1.6 problem.

does this happen while a sketch is running or just anytime?

I run some tests in both 136 and 135.

I start up with an empty sketch and by example open 'Beziercurve' through
the icon 'open'.
The window that opens up with that sketch won't run. If I copy the content
to the clipboard and past it back to the empty sketch THAT window will run.
If I try to load a file through the File menu I get some freezes with a
spinning wheel ( nothing works anymore, not even the dock ).
When the machine comes to live I am not able to run that sketch either, but
the first window with the pasted example still does.


(In reply to comment #3)
>
>
>
> Additional Comment #3 From
>
> fry
> 2008-05-31 09:17
>
> <!--
> addReplyLink(3); //-->[reply]
>
>
>
>
> does this happen while a sketch is running or just anytime?
>
>

that's a different problem, covered by bug #784.

use this bug report just for the slow menu issue. did you try what i wrote
in comment #2 to see if it fixed the slow menus? quit processing, make that
change, and then start it again to see if the menus behave better.

I did this test:

I changed the JVMVersion from 1.5+ to 1.5* for both 136 and 137 and that
doesn't change a thing. I now even changed the JVMVersion back to 1.4* .
Then 136 opens up the menu normal but running the opened sketch crashes
Processing. 137 in 1.4. mode won't start because of a message that the Java
version is incorrect.

k, so apple just screwed something up in 1.5... will need to do a
workaround. the 0137 behavior (saying that 1.5 is needed on startup) is
correct. thanks for checking.

can you try this in 0138? i'm having trouble getting it to reproduce with
the current code.

Tried the test with 138.
Delay and spinning wheel iare still there altough the eventualy loaded
sketches are running now.
(Looks like bug 784 is fixed).

Got the latest 139 code through SVN
No change so far, still spinning wheels.
Running the 139 give these two results:
A 64-bit JVM is available for 1.5.0
JVMArchs not found in Java dictionary

Little test:
Changed in Base.java

if (Base.isMacOS()) {
// Use the Quaqua L & F on OS X to make JFileChooser less awful
//UIManager.setLookAndFeel("ch.randelshofer.quaqua.QuaquaLookAndFeel");
UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel");
// UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
// undo quaqua trying to fix the margins, since we've already
// hacked that in, bit by bit, over the years
UIManager.put("Component.visualMargin", new Insets(1, 1, 1, 1));

Menu inside processing window is reacting normally now -> looks like quaqua
or systemLook is the bugger

try adding this to the Info.plist, next to the jvm stuff:

<key>JVMArchs</key>
<array><string>x86_64</string> <string>i386</string> <string>ppc</string>
</array>

and restarting with that. i wonder if it's a 32/64 bit problem.

i was hoping you meant that quaqua was the problem, but to be clear, the
system look and feel is broken too, right?

also, are you running any other kernel extensions (some sort of key
accelerators.. anything that would manipulate menus.) i still haven't been
able to reproduce this.

Entered sugested keys into the Info.plist. Processing 138 does use the 64
bit JVM. The problem is still there. Looked for kext in Extensions but
nothing remarkble found. If I place a 'false' into the Info.plist
Root.Java.property of apple.laf.useScreenMenuBar then the menu comes
without any problem inside the Processing screen. Even changed the
quaqua.jar with a newer one. No result.


(In reply to comment #12)
>
>
>
> Additional Comment #12 From
>
> fry
> 2008-06-01 05:39
>
> <!--
> addReplyLink(12); //-->[reply]
>
>
>
>
> try adding this to the Info.plist, next to the jvm stuff:
>
> <key>JVMArchs</key>
> <array><string>x86_64</string> <string>i386</string> <string>ppc</string>
> </array>
>
> and restarting with that. i wonder if it's a 32/64 bit problem.
>
> i was hoping you meant that quaqua was the problem, but to be clear, the
> system look and feel is broken too, right?
>
>

Did the test on several other Macbooks ( Pro) all with 10.5.3
They all have this problem accept those machine's did not have that many
Sketches in their sketchbook as I have. The lock-up / color spinningwheel
is determined by the number of sketches
available. So I guess the problem can be reproduced by using a 10.5.3. Mac
and Processing 136+
with a lot of sketches in the sketchbook.

The bug can be reproduced by placing my archive of Sketches on an other Mac
with 10.5.3 and Processing 136+.
The same long delay and colored spinning wheel shows up.
It does not happen when starting up 135.

(In reply to comment #15)
>
>
>
> Additional Comment #15 From
>
> iching@xs4all.nl
> 2008-06-02 05:55
>
> <!--
> addReplyLink(15); //-->[reply]
>
>
>
>
> Did the test on several other Macbooks ( Pro) all with 10.5.3
> They all have this problem accept those machine's did not have that many
> Sketches in their sketchbook as I have. The lock-up / color spinningwheel
> is determined by the number of sketches
> available. So I guess the problem can be reproduced by using a 10.5.3. Mac
> and Processing 136+
> with a lot of sketches in the sketchbook.
>
>

try changing the Info.plist of 0135 to say 1.5* instead of 1.4* for the
java version. i assume that will cause the same problem in 0135.

Changed the Info.plist parameter 1.4* to 1.5* of the 135 version and the
problem als arise in this version. So probably Java 1.5 and 6 are to blame.
For me the workaround is setting the Info.plist parameter
apple.laf.useScreenMenuBar to false. No real apple menu but a menu inside
the Processing window.

(In reply to comment #17)
>
>
>
> Additional Comment #17 From
> fry
> 2008-06-03 05:17
>
> <!--
> addReplyLink(17); //-->[reply]
>
>
>
>
> try changing the Info.plist of 0135 to say 1.5* instead of 1.4* for the
> java version. i assume that will cause the same problem in 0135.
>
>

Thanks, so that confirms it as a problem in Apple's Java 1.5 on OS X 10.5.
Now to find a workaround...

k, spent some time looking into this one. i was hoping that part of the
issue was either:

1) the way we do menu handling across multiple windows (using insert() to
move the submenus around), but it's not

2) the way we set an ActionCommand for each menu item, however it still has
the same problem when that's disabled.

i've also (re)confirmed that:

1) this is a problem with both Java 1.5 and 1.6 (64 bit) on OS X 10.5, and
1.4 is not affected.

2) enabling/disabling the quartz renderer in the Info.plist doesn't affect
anything.

the current workarounds:

1) change the Processing.app Info.plist to point at 1.4* instead of 1.5*.
that's not likely to work very long.

2) change the Processing.app Info.plist to set apple.laf.useScreenMenuBar
to false. this makes an ugly menubar inside the window, but things work again.

3) (perhaps the best) use the popup menus inside the the window, which is
not affected by the problem. only issue here is that opening a file from
the toolbar will replace the current sketch in that window, so you just
have to hit cmd-N before selecting "Open" from the toolbar.

the current todo items:

1) make a simple, pure java test case that emulates the behavior of the
sketchbook menu (a dozen items, a few subitems, etc) so i can post to
apple's bugs database, and see if they'll fix it. we need to reproduce the
problem separate from the p5 code base before they'll listen.

2) not much else to do in the meantime, until we've verified the problem
via #1 (it may still turn out to be p5, of course) and complain to apple
about it.

** if anyone can help with this todo item, please do so! **

(In reply to comment #20)
>
>
>
> Additional Comment #20 From
> fry
> 2008-06-03 15:11
>
> <!--
> addReplyLink(20); //-->[reply]
>
>
>
>
> k, spent some time looking into this one. i was hoping that part of the
> issue was either:
>
> 1) the way we do menu handling across multiple windows (using insert() to
> move the submenus around), but it's not
>
> 2) the way we set an ActionCommand for each menu item, however it still has
> the same problem when that's disabled.
>
> i've also (re)confirmed that:
>
> 1) this is a problem with both Java 1.5 and 1.6 (64 bit) on OS X 10.5, and
> 1.4 is not affected.
>
> 2) enabling/disabling the quartz renderer in the Info.plist doesn't affect
> anything.
>
> the current workarounds:
>
> 1) change the Processing.app Info.plist to point at 1.4* instead of 1.5*.
> that's not likely to work very long.
>
> 2) change the Processing.app Info.plist to set apple.laf.useScreenMenuBar
> to false. this makes an ugly menubar inside the window, but things work
again.
>
> 3) (perhaps the best) use the popup menus inside the the window, which is
> not affected by the problem. only issue here is that opening a file from
> the toolbar will replace the current sketch in that window, so you just
> have to hit cmd-N before selecting "Open" from the toolbar.
>
> the current todo items:
>
> 1) make a simple, pure java test case that emulates the behavior of the
> sketchbook menu (a dozen items, a few subitems, etc) so i can post to
> apple's bugs database, and see if they'll fix it. we need to reproduce the
> problem separate from the p5 code base before they'll listen.
>
> 2) not much else to do in the meantime, until we've verified the problem
> via #1 (it may still turn out to be p5, of course) and complain to apple
> about it.
>
> ** if anyone can help with this todo item, please do so! **
>
>


I can put together a Java Menu system over the weekend. Please just confirm
if this is still needed. -ira

yeah, thanks--it shouldn't take more than a couple minutes--just make a
quick java program that creates a menu with a few options, then some long
submenus. then test the beast with 1.4 and 1.5 on OS X 10.5 and make sure
we're seeing the slowdown there.

Would be very nice to have a bug-reproducer-that-I-can-test ;-)


(In reply to comment #22)
>
>
>
> Additional Comment #22 From
> fry
> 2008-06-05 04:58
>
> <!--
> addReplyLink(22); //-->[reply]
>
>
>
>
> yeah, thanks--it shouldn't take more than a couple minutes--just make a
> quick java program that creates a menu with a few options, then some long
> submenus. then test the beast with 1.4 and 1.5 on OS X 10.5 and make sure
> we're seeing the slowdown there.
>
>

(In reply to comment #22)
>
>
>
> Additional Comment #22 From
> fry
> 2008-06-05 04:58
>
> <!--
> addReplyLink(22); //-->[reply]
>
>
>
>
> yeah, thanks--it shouldn't take more than a couple minutes--just make a
> quick java program that creates a menu with a few options, then some long
> submenus. then test the beast with 1.4 and 1.5 on OS X 10.5 and make sure
> we're seeing the slowdown there.
>
>

ok, will do

(In reply to comment #23)
>
>
>
> Additional Comment #23 From
> iching@xs4all.nl
> 2008-06-05 07:45
>
> <!--
> addReplyLink(23); //-->[reply]
>
>
>
>
> Would be very nice to have a bug-reproducer-that-I-can-test ;-)
>
>
> (In reply to comment #22)
> >
> >
> >
> > Additional Comment #22 From
> > fry
> > 2008-06-05 04:58
> >
> > <!--
> > addReplyLink(22); //-->[reply]
> >
> >
> >
> >
> > yeah, thanks--it shouldn't take more than a couple minutes--just
make a
> > quick java program that creates a menu with a few options, then some long
> > submenus. then test the beast with 1.4 and 1.5 on OS X 10.5 and make sure
> > we're seeing the slowdown there.
> >
> >
>
>

Unfortunately, I didn't see any slowdown using ridiculously long
menus/submenus. I tested 1.4 and 1.5 (32 and 64 bit) on OS X 10.5.3.

hm, can you post that code anyway so i can use it as a starting point?

>> 2) change the Processing.app Info.plist to set apple.laf.useScreenMenuBar
>> to false. this makes an ugly menubar inside the window, but things work
again.
>>
>> 3) (perhaps the best) use the popup menus inside the the window, which is
>> not affected by the problem. only issue here is that opening a file from
>> the toolbar will replace the current sketch in that window, so you just
>> have to hit cmd-N before selecting "Open" from the toolbar.

Unfortunately, with both of these solutions, there is a problem: with
enough sketches on the list to fill up the screen, you can't get to the
scroll bar, so you are forced to go to the "Open" option directly. Not a
huge deal, but I'm going to submit this as a separate bug anyways.

menus filling up the screen is bug #391
http://processing.org/reference/troubleshooting/index.html#cantfix

(In reply to comment #26)
>
>
>
> Additional Comment #26 From
>
> fry
> 2008-06-09 12:13
>
> <!--
> addReplyLink(26); //-->[reply]
>
>
>
>
> hm, can you post that code anyway so i can use it as a starting
point?
>
>
I'm at a conference through tonight. I'll post in a day or so.

Bug persists with Processing 0140

System Info:

Mac OS X 10.5.3

Darwin Macintosh-4.local 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:51:20 PDT 2008;
root:xnu-1228.5.18~1/RELEASE_PPC Power Macintosh
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)

In version 141 the menus show up significant faster then in 139 , no
spinning color wheels.
A liitle delay is there but not annoying.

(In reply to comment #30)
>
>
>
> Additional Comment #30 From
> ajstarks
> 2008-06-11 18:52
>
> <!--
> addReplyLink(30); //-->[reply]
>
>
>
>
> Bug persists with Processing 0140
>
> System Info:
>
> Mac OS X 10.5.3
>
> Darwin Macintosh-4.local 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23
00:51:20 PDT 2008;
> root:xnu-1228.5.18~1/RELEASE_PPC Power Macintosh
> java version "1.5.0_13"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
> Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)
>
>
>
>

(In reply to comment #29)
>
>
>
> Additional Comment #29 From
> irag
> 2008-06-11 10:02
>
> <!--
> addReplyLink(29); //-->[reply]
>
>
>
>
> (In reply to comment #26)
> >
> >
> >
> > Additional Comment #26 From
> >
> > fry
> > 2008-06-09 12:13
> >
> > <!--
> > addReplyLink(26); //-->[reply]
> >
> >
> >
> >
> > hm, can you post that code anyway so i can use it as a starting
> point?
> >
> >
> I'm at a conference through tonight. I'll post in a day or so.
>
>
>

The problem only seems to occur when useScreenMenuBar="true",
eg:
java -Dapple.laf.useScreenMenuBar="true" MenuExample2

In default mode (false), I get no delay at all.

Also, for me there was no evident improvement in 141.

Dumb menu code i used is downloadable at: http://iragreenberg.com/menu_code.zip

So yes, it does look like an apple (Java look and feel") issue.

edit]
Java test case from Ira

Submitted to bugreporter.apple.com as bug id 6034650.

Anyone else annoyed with this one please file a bug with Apple.

> Submitted to bugreporter.apple.com as bug id 6034650.
>
> Anyone else annoyed with this one please file a bug with Apple.
Done.

This is def. a 1.4 v 1.5 thing, btw, and I just put together a simple
demonstration (hadn't realized Ira already did it, but I'll post it anyways
- this very clearly shows the performance regression between 1.4 and 1.5) :

import javax.swing.JFrame;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;

public class SwingMenuSlowdown {
public static void main(String[] args) {
System.setProperty("apple.laf.useScreenMenuBar", "true");
JFrame frame = new JFrame();
frame.setTitle("On OS X this menu is really slow in Java 1.5+, but works
fine in 1.4");
frame.setSize(640,480);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JMenuBar myMenuBar = new JMenuBar();
JMenu myFile = new JMenu("File");
JMenu mySub = new JMenu("A lotta stuff");
for (int i=0; i<300; ++i) {
mySub.add(new JMenuItem("MyStuff "+i));
}
myFile.add(mySub);
myMenuBar.add(myFile);
frame.setJMenuBar(myMenuBar);
frame.setVisible(true);
}
}

Granted a 300 item submenu is a bit much, but the point is that this is
still usable in 1.4, and the pause is obnoxious in 1.5, so that's a pretty
serious regression (Apple's, not Processing's).

We'll see if they address it - best case I'd guess it might show up in a
1.6 update, since I doubt Apple is updating the 1.5 VMs much anymore...

*** Bug 873 has been marked as a duplicate of this bug. ***

I'll just repeat, for anyone having trouble with this, please file a bug
with Apple at bugreporter.apple.com. They won't listen to developers and
Java is a very low priority for them, but if enough users complain, they
may fix it.

(In reply to comment #37)

FYI, I have sumbitted the bug to Apple (bug# 6149778); they have acknowledged the bug as
a known issue, and a duplicate to 6034650


> I'll just repeat, for anyone having trouble with this, please file a bug
> with Apple at bugreporter.apple.com. They won't listen to developers and
> Java is a very low priority for them, but if enough users complain, they
> may fix it.
>
>

(In reply to comment #38)
>
>
>
> Additional Comment #38 From
> ajstarks
> 2008-08-21 09:07
>
> FYI, I have sumbitted the bug to Apple (bug# 6149778); they have
acknowledged the bug as
> a known issue, and a duplicate to 6034650

Thanks a lot, they haven't even bothered responding to the original report
to confirm it or mark it as a known issue, so it's helpful to at least have
some kind of feedback from them.

And for anyone else, please continue to file reports until Apple fixes it.

This now seems to affect 10.4 as well, they may have successfully
backported the bug to 10.4 with the Java for Mac OS X 10.4 Release 7. Yay!

Again, for anyone reading/annoyed by this, please file a bug with
Apple--they won't fix things unless they understand that there's any sort
of priority to it.

(In reply to comment #40)
> Additional Comment #40 From
> fry
> 2008-10-11 10:31
>
> <!--
> addReplyLink(40); //-->[reply]
>
> This now seems to affect 10.4 as well, they may have successfully
> backported the bug to 10.4 with the Java for Mac OS X 10.4 Release 7. Yay!
>
> Again, for anyone reading/annoyed by this, please file a bug with
> Apple--they won't fix things unless they understand that there's any sort
> of priority to it.

Filed an additional new bug report <a
href="https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/73/wo/IXJWlaYqG9VHvBDsy9eIzw/16.34">6294376</a>.
I hope Apple will eventually get to fix that one as it is pretty annoying...

Sure is, thanks for filing the report.

I also reported this to Apple and they gave me the bug id #6286837. They said:

"This issue has been filed in our bug database under the original Bug ID#
6034650"

They also said:

"We truly appreciate your assistance in helping us discover and isolate bugs."

They didn't say whether they would fix the bug - either as 6286837 or the
original 6034650 :)

Right, I still don't have any sort of confirmation from the original
report. Oh well.

Although the ball appears to be in Apple's court, the problem appears
specifically related to menus with dynamic contents: File, Sketch and Help.
The Edit and Tools menus appear instantly.

No, the ball is *entirely* in Apple's court. The reason that Edit and Tools
show up is because they aren't more than a couple items. The bug
specifically has to do with having lots of entries in the menubar. The help
menu problem appears to be something related to Apple's help system. On
some 10.5 machines, using the Help menu can crash (application unexpectedly
quit errors) the application entirely.

Someone from Apple has finally responded to the bug report saying that it's
a duplicate of bug #
5583869 and that it's a known issue (whatever that means, more than six
months later).

However, if the issue is affecting you, please file a report with Apple so
that they know the extent and number of users affected by the problem.

For 0158, we're disabling the regular screen menu bar on OS X 10.5 and
placing the menu bar inside the editor window as a workaround until Apple
fixes the bug.

The first time you run on OS X 10.5, it will bring up a warning dialog.
After that the menu bar in its regular location is disabled. If you want
the menu bar at the top of the screen, you can edit preferences.txt (when
Processing is not running). Change the line:

apple.laf.useScreenMenuBar=false

to read:

apple.laf.useScreenMenuBar=true

The file can be found at Home > Library > Processing > preferences.txt

And once again, for anyone who finds this frustrating, please file a bug
with Apple. We've done all we can at this point.

hey fry, I'm in no way familiar w/ java and apple bugreport system, so I'd really like to help
filing a bug but I don't know what to write in the bugreport... any hint?

Visit bugreporter.apple.com, and if you don't have one, sign up for a
(free) account with Apple.

Follow the instructions in the bug reporter tool, see comment #35 for code
that reproduces the bug in straight Java that you can add to the post (they
don't really know what Processing is, so they don't really care about the
app being broken).

Thanks all.

done, marked as id# 6407924

hope this will help!

Thanks!

Also: Bug ID# 6418398

as for someone before, mine has been marked as duplicate of bug#5583869 "which is currently
being investigated by engineering" blah blah blah...

cheers!

Great, thanks all. Let's hope they get around to fixing it.

rrraaaah!!! java update for Leopard and the bug's still there!!!
how can they completely ignore us!!?!

damnit...

You can also write to the support/feedback page, their developers have
mentioned that as well... I don't think they understand/believe(/care?) how
many users we have that are affected by this.

Windows and Linux machines also tend to run Java consistently better than
the Mac, so there's always an alternative. Java is clearly a very low
priority for Apple and it's frustrating to deal with this.

I've given up hope on Apple ever fixing their bug, so for 1.0.4, the menu
behavior will change.

By default, File > Sketchbook and File > Examples will be disabled on OS X.
You can use the "Open" popup menu on the toolbar to access the same
material, so this is probably a better solution all around. I'll leave the
entry in the Preferences window for people who want to place the menubar in
the window, to get the old menubar behavior.

The Apple bug seems to have been fixed in their latest Java update (Java for Mac OS X v10.5
Update 4). The test cases in this thread now run fine on my 2007 Macbook with the update
applied.

Tested for the spinning wheel bug after upgrading Java to number 4 .
No spinning wheel anymore on P5 version 1.03 :-) :-) :-)
Can not test on version 1.05 because Sketches and Examples are grayed out

yeah. late but they did it!!! they're taking a good direction with all the
snow leopard thing :)

please fry reenable these menus! (I'm still with 1.03)
thanks :)

They've introduced some serious bugs in update 4 with regards to other menu
handling issues (see Apple's java-dev list), so I'm holding off on making
the change until they get things straightened out (and stop messing with
the menu code). I don't want to rip out all the workarounds I have in
there, only to have Apple go back to the previous version of the menu code
and re-introduce the problem.

(In reply to comment #62)
> That's a really stupid hanging bug.
That's the first time I tried Processing, which I downloaded in the first
place because art is my business, code isn't that much. And of course the
first thing any beginner wants, is a seemingly flawlessly working app and
some examples to start with.

Well here I'm welcomed right away with a bug message on a regular osx, and
it's not easy to reach the examples...
>
>
> Additional Comment #62 From
> fry
> 2009-06-25 11:47
>
> <!--
> addReplyLink(62); //-->[reply]
>
>
>
>
> They've introduced some serious bugs in update 4 with regards to
other menu
> handling issues (see Apple's java-dev list), so I'm holding off on making
> the change until they get things straightened out (and stop messing with
> the menu code). I don't want to rip out all the workarounds I have in
> there, only to have Apple go back to the previous version of the menu code
> and re-introduce the problem.
>
>

Follow the instructions in the error message, and use the Open button on
the toolbar, which gives easy access to all the examples.

For 1.0.8, the menu disabling and warning message are now gone. The bug
seems to have been fixed in recent Java releases. If you're still having
trouble, run Software Update.

hey fry! it's intentional that Sketchbook and Examples menus are still
grayed out in 1.0.8? when do you plan to enable them back again?
thanks, kiwi ;)

ooog... you're right. they should not be dimmed, there's still a minor
problem. will fix in the next couple days.

fixed again for 1.0.9.

I want to report that everything is working ok now in 1.0.9 :-)

My setup: P5 1.0.9 / Mac OSX 10.6.1 and many, many projects in my sketchbook.
No more spinning wheel.

I am still getting this color wheel slow response in the file tab
version 1.0.9.

It is very annoying. How do I get rid of it?

Mac OS X
version 10.5.7