OS X 10.10 (Yosemite): Preview fails to keep up with fast window resizing

Posted by Pierre Igot in: Macintosh
March 6th, 2015 • 5:56 pm

Here’s a typical example of the many things that are wrong in Yosemite in terms of performance and responsiveness. When you first upgrade to Yosemite, you might notice all kinds of different responsiveness issues and it can be all quite confusing, giving you a general impression of unresponsiveness even though you cannot quite clearly pinpoint what is wrong.

Over time, however, it gradually becomes easier to identify specific behaviours in specific applications that help explain this general impression. Here is one such specific behaviour.

It has to do with the Preview application and with what happens when you view a PDF in “Single Page” view mode and you resize the window to make it bigger.

In order to reproduce the problem you need to do the following:

  1. Open a PDF file (any PDF file will do) in Preview.
  2. In Preview, go to the “View” menu and select the “Single Page” option (as opposed to the default “Continuous Scroll”).
  3. Then grab the bottom-right corner of the window and resize it to make it quite small.
  4. Then grab the bottom-right corner of the window again and drag it to the right and down as fast as you can with your mouse.

The speed is important here. If you drag it at a “normal” speed, you won’t encounter any problems.

If you drag it fast enough, on the other hand, sooner or later this will happen:

(Click here to get the MP4 video on DropBox.)

Note the situation in the video around the 02:00 mark: Even though the window’s bottom-right corner is near the edge of the video frame, the bottom-right corner of the PDF page is nowhere near that edge. It’s because I’ve resized the window too fast for Preview, and it has failed to keep up with my mouse movement.

But I’ve kept my mouse button down. And around the 03:00 mark, I nudge the mouse pointer a little bit more, which forces Preview to finally refresh its display of the PDF page so that it properly fills the space available inside the window’s edge (allowing for a tiny bit of padding for esthetic reasons, of course).

How pathetic is this? My hardware is not to blame: I have a very powerful 2014 Mac Pro with tons of RAM, and there’s nothing running in the background that would excuse such a shortcoming. (In actual fact, the ScreenFlow application is running and recording all this in real time, of course, but this behaviour is perfectly reproducible even when ScreenFlow is not running.)

Now, you might be tempted to say: “Yeah, but who resizes at that speed with the mouse anyway? If you resize at a more ‘normal’ speed, there is no problem here.” And that might be what Apple’s engineers think. (In other words, things are “good enough” for most users here.)

Well, for one thing, this is a pretty sad attitude to have. There is no question that my Mac is powerful enough and that Preview should not be struggling with this. Any self-respecting engineer who strives for excellence in his or her work should be dissatisfied with this and insist that the problem be fixed.

And then there’s the fact that it effectively penalizes users for being too fast! In what world is that considered OK? We live in an age of superfast hardware that should have no trouble keeping up with human interactions, especially when everything is local and no networking is involved. Yes, I am a fast user. So what? Does it really make me a bad user?

Finally, there’s one more thing: This shortcoming has a significant impact on people who, like me, might use Keyboard Maestro to automate various tasks, including the moving and resizing of windows in OS X. I have two large monitors and I have several macros that enable me to automatically move and resize my windows in any OS X application, including Preview, so that I can easily organize my document windows side by side on either screen.

I often have four different documents open in four different windows side by side and my large screens enable me to me to view these documents at a fairly low zoom level while maintaining legibility. But the two screens do not have the same size/resolution, and so when I switch a document window from one screen to the other I need to resize it. If that resizing involves a PDF document open in a window in Preview, then guess what happens?

Well, for window manipulation, Keyboard Maestro’s macros effectively behave like a superfast user, mimicking mouse movements at the fastest possible speed. So of course they are going to be affected by this bug in Yosemite’s Preview application. Sure enough, every time I use a macro that includes a step like this one:


and the window involved happens to be on my second screen, where the window size has to be smaller, the macro correctly moves it to the main screen and correctly resizes the window to fill the bigger screen, but Preview fails to keep up with it and so the PDF page in the window is not resized properly.

In fact, Keyboard Maestro is faster than I’ll ever be with my mouse, and it’s so fast that Preview fails to resize the PDF page itself altogether! The window is bigger, but the PDF page keeps the same size it had on the secondary screen.

The only solution that I have found to work around this problem is to add an extra step to the macro, just for Preview:


This extra step effectively mimicks the little nudge illustrated around the 03:00 mark in the video above, which forces Preview to refresh its display of the PDF page so that it finally fills the space available inside the window.

But it’s not an ideal solution, because any extra step like this increases the risk that something might go wrong during the execution of the macro. If Yosemite experiences any kind of “hiccup” during the execution (which it tends to do), then the nudge might not work as expected and I will still have to resize the window manually in order to force Preview to refresh its display of the PDF page.

This is a new problem in Yosemite. Preview in Mavericks never had such a problem, and I had been using my Keyboard Maestro macros with it for a long time without a hitch.

When people talk about Apple’s sloppy work in Yosemite, I believe that this is the kind of thing that they are thinking of. It took me a while to narrow it down because of all the other responsiveness problems I was having with Yosemite, but this, as far as I can tell, is an easily reproducible problem for anyone running Yosemite, even people who don’t have the egregious responsiveness problems that I have been experiencing.

When will Apple get around to fixing it (if ever)? Unfortunately, because the application works “well enough” for the majority of users, I am not too optimistic, which is why I’ll have to keep this extra “nudge” step in my macros and in my own dragging movements for quite a while, I fear.


Comments are closed.