Bug 965 – Rendering zoomed images in a stack is very slow on OS X 10.10 Yosemite

Bug 965 - Rendering zoomed images in a stack is very slow on OS X 10.10 Yosemite


Summary:	Rendering zoomed images in a stack is very slow on OS X 10.10 Yosemite

Status:	RESOLVED FIXED

Product:	Fiji
Classification:	Unclassified
Component:	ImageJ2
Version:	unspecified
Hardware:	Macintosh Mac OS

Importance:	P4 normal
Assigned To:	ImageJ Bugs Mailing List

URL:

Depends on:
Blocks:

Reported:	2014-11-30 14:10 CST by Tim Smith
Modified:	2015-06-08 13:33 CDT
CC List:	4 users (show)

See Also:

Description Tim Smith 2014-11-30 14:10:54 CST

Scrolling through an image stack (i.e. with a scroll wheel) is very fast on OS X 10.9 Mavericks. After upgrading to Yosemite, there's a visible refresh lag as the frame is redrawn if the image is zoomed above 100%.

To reproduce:
1. Open an image stack. (I uploaded "22.jpg.tif" as an example; open it with the ImageIO importer.)
2. Scroll through it; should not observe any refresh lag.
3. Zoom to 150%.
4. Scroll through the stack; should observe visible refresh lag on 10.10 but not 10.9.

I haven't tried to reproduce the slowness on another system yet.

Information about your version of Java:

  os.arch => x86_64
  os.name => Mac OS X
  os.version => 10.10.1
  java.version => 1.8.0_20
  java.vendor => Oracle Corporation
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.8.0_20-b26
  java.vm.name => Java HotSpot(TM) 64-Bit Server VM
  java.vm.version => 25.20-b23
  java.vm.vendor => Oracle Corporation
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.CGraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.8
  sun.cpu.endian => little
  sun.desktop => null
  file.separator => /

The up-to-date check says: REMIND_LATER

Information relevant to JAVA_HOME related problems:

  JAVA_HOME is set to: null
  imagej.dir => /Applications/Fiji.app

Information about the version of each plugin:

Activated update sites:
ImageJ: http://update.imagej.net/ (last check:20141126131327)
Fiji: http://fiji.sc/update/ (last check:20141125081145)

Files not up-to-date:
  4de2d197 (MODIFIED) 20140808173056 Contents/Info.plist
  54c31af9 (LOCAL_ONLY) 20130628102825 plugins/Image_Correlator.class

Comment 1 Wayne Rasband 2014-11-30 14:49:51 CST

The Graphics.drawImage() method is very slow with Java 1.7 and Java 1.8 on OS X. You can avoid this problem by using Java 1.6, which can be downloaded and installed on Yosemite from <http://support.apple.com/kb/DL1572>.

Comment 2 Tim Smith 2014-11-30 16:13:46 CST

Sure enough, thanks! Installing the Apple Java 6 package and restarting Fiji fixed the problem (and bounced ImageJ back to Java 1.6) without altering the function of /usr/bin/java, which is a Yosemite-provided Java 8. Sorry if I missed some documentation on this.

I'd previously installed that Java package on Mavericks but upgrading to Yosemite cleaned it out.

Comment 3 Joel Uckelman 2015-01-02 16:11:14 CST

I happened upon this bug report when investigating the poor rendering performance we're seeing in VASSAL with Java 7 and Java 8 on Yosemite. It looks as though we're hitting the same bug, as Java 6 doesn't exhibit the problem for us.

The bug in our tracker is here:

  http://www.vassalengine.org/tracker/﷒0﷓

And here's the thread in our forum:

  http://www.vassalengine.org/forum/viewtopic.php?f=3&t=7716

Have you made any progress on determining what the cause of the regression is, or whether there's a workaround other than reverting to Java 6?

Comment 4 Curtis Rueden 2015-01-16 16:31:28 CST

Sorry for the delay in reply, Joel. Unfortunately, no one has had time to investigate this issue further yet. There is some talk of migrating ImageJ to Java 7 or 8 eventually (http://imagej.net/pipermail/imagej-devel/2014-December/002357.html, https://list.nih.gov/cgi-bin/wa.exe?A2=IMAGEJ;405483db.1501); it would be ideal to address this issue before that happens, due to the performance implications. But I'm afraid I have no news right now regarding how to solve it from a technical perspective.

Comment 5 Joel Uckelman 2015-01-16 17:07:58 CST

I'll be sure to let you guys know should we discover anything relevant.

Comment 6 Curtis Rueden 2015-01-16 17:24:51 CST

Likewise!

Comment 7 Curtis Rueden 2015-06-08 13:33:03 CDT

For any who don't already know: as of Java 1.8.0_45 (and possibly some earlier versions -- not sure), the horrible paint performance has been addressed. So I am closing this issue. Just update to the newest Java to resolve the problem.