Open ctrueden opened 9 years ago
We really need to address these performance problems, since it seems the latest Oracle Java 8 on OS X still has this problem. It was recently brought up again on the mailing list. And I'm sure it will keep being brought up until ImageJ stops having these problems with Java 8 on OS X.
Apple just released macOS Sierra (10.12) but it does not fix this issue, unfortunately. (I thought it might, since it does appear to fix at least one memory leak.)
Not sure whether this is still an issue, but leaving it open for the moment. Probably what will happen is that we won't do the "hacking ImageJ menu bar to be a JMenuBar
" idea, in favor of putting more TLC into the ImageJ2 Swing UI, details TBD.
Not sure whether this is still an issue, but leaving it open for the moment. Probably what will happen is that we won't do the "hacking ImageJ menu bar to be a
JMenuBar
" idea, in favor of putting more TLC into the ImageJ2 Swing UI, details TBD.
It is, at least on my Apple Silicon machine. Switching between ImageJ main menu and Command Finder incurs an ever growing lag. While this looks like a synthetic scenario, it mimics what happens when I switch between multiple images, ROI Manager, and Brightness & Contrast. Imagine inspecting hundreds of ROIs in several imaging modalities. Upon SetMenubarCount ~200, the setMenubarTime approaches 2000ms, and the bar is gone.
Curiously, it appears fine on x86_64 Windows (I checked the code, setMenuBar(mb) upon focus is unconditional for Command Finder). On windows, the menubar for the ImageJ main windows visibly flashes when I bring Command Finder in focus, and the time taken is consistent. It seems also fine on my old Intel Mac running macOS 10.13 (and a recent JRE 8u400+, recent ij1.54k) - the menubar blackout is noticeable, but consistent.
If someone can test this on an Intel Mac running maybe Sonoma, we'd finally be sure what went wrong. Either it's something specific to ARM, or some change on Apple's side that does not play well with Java's way of handling Menu items.
Thanks @Jerry1144 for summarizing your findings. I will keep this performance issue in mind for any new GUI that gets developed. (Can't promise any timelines there yet, unfortunately.)
As for the Command Finder: are you using Fiji? If you use the search bar instead of the original ImageJ's Command Finder, do you still see increasing performance issues with menu bars?
As for the Command Finder: are you using Fiji? If you use the search bar instead of the original ImageJ's Command Finder, do you still see increasing performance issues with menu bars?
The Quick Search windows is not triggering this issue. No flashes to the system menu bar, which is also true for Results window and Get Info. Yet the legacy behavior of:
ImageJ1's normal behavior of assigning the MenuBar to each window as it is activated.
Is still a hassle – ROI Manager, B&C, and all normal image windows possess this behavior. I can not avoid them.
I have a gut feeling that transferring menus from one window to another is not so simple as a set
call. Like, set semantically means copy/retain, instead of move. Even as the Java API forbids multiple windows using a same menu object, it may well be copying one over, and not dealing with the possibility that it was in use by another frame. Well, at least I saw no checks for that in https://github.com/openjdk/jdk8u/blob/master/jdk/src/macosx/native/sun/awt/CMenu.m
Maybe clear it from a previous window immediately before the setMenuBar(mb)
?
You can eliminate the window switching delays on macOS by enabling the "Don't set Mac menu bar" option in the Edit>Options>Misc dialog. You can test this option using the the following macro. It requires the latest ImageJ daily build (1.54m28), which adds the setOption("setIJMenuBar",boolean) macro function and fixes a bug where the Command Finder ignored this option. You will see that this macro runs much slower when you change 'false' to 'true' in the first line.
setOption("setIJMenuBar", false); // requires 1.54m28
run("Find Commands...");
t0 = getTime;
for (i=0; i<50; i++) {
selectWindow("Command Finder");
selectWindow("ImageJ");
}
print("time="+(getTime-t0)/1000+" seconds");
This issue has been mentioned on Image.sc Forum. There might be relevant details there:
Upgrade to the latest daily build (1.54m29) and the Command Finder and ROI Manager will not set the ImageJ menu bar on macOS. Image windows will not set the ImageJ menu bar if you enable “Don’t set Mac menu bar” in the Edit>Options>Misc dialog or use the setOption(“SetIJMenuBar”,false) macro function.
Upgrade to the latest daily build (1.54m29) and the Command Finder
I wonder it was intentional to refresh the menu upon Command Finder. It's one of the rare places that sets the menubar on Windows too.
and ROI Manager will not set the ImageJ menu bar on macOS.
Thank you!
Still, may I suggest an additional global weak_ptr Window mb_holder
to live alongside the global Menubar mb
, such that each call to if (setmenubar) {setmenubar(mb)}
is instead something like
if (setmenubar) {
if (mb_holder != nil) {
mb_holder.clearMenuBarExcludingAppleMenu_OnAppKitThread(excludingapplemenu:true)
}
setmenubar(mb)
mb_holder = self
}
Oracle Java 7 and 8 (including 1.8.0_66) have a severe performance problem when attaching an AWT
MenuBar
to new windows. See this forum thread for details.One probable workaround is to use
com.apple.eawt.Application.setDefaultMenuBar(JMenuBar)
to set a default menu bar which gets reused by every window (including AWTFrame
windows, nicely). However, ImageJ Legacy will need to build aJMenuBar
which matches the ImageJ1MenuBar
, then suppress ImageJ1's normal behavior of assigning theMenuBar
to each window as it is activated.This will probably be rather involved, and might not be worth the effort. Time will tell whether users continue to suffer performance problems with Java 8 on OS X—if so, we can consider tackling this project then.
See also SO #16175884.