PPro CS5 GUI on mac really jerky

[parkerbri]

Moving clips around on the timeline of CS5 on the mac is like playing Russian roullette; you never know where the clip is actually going to fall. It's like the interface has a refresh rate of 5fps or something. It seems to take forever for clips to snap against each other, and this lag causes the user to think something is wrong and then move the clips around more than necessary.

Please please tell me that this will be addressed in a point release. I don't want to have to pay to upgrade for a solution to a problem that should never have made it to a full release.

[LFedit]

Ran across this thread after trying to find alternative solutions to this problem which Butch2oc posted a possible solve to the issue in this thread: http://forums.adobe.com/thread/785985,

It appears to be a screen resolution issue, dragging  the timeline panel to a lower resolution display, or minimizing the  amount pixels the timeline takes up improves performance for me.  Its not the  greatest solution when your working with 10-20 layers, but it does help  drag clips around more smoothly.  Is this consistent for other Mac users?

[Keith Moreau]

Paul, it looks like Will in post #111 has a modern Mac and is saying he doesn't have the issue, and that his response is similar to your video part 4, which has very good response, on your older Mac. It looks like he has a pretty new machine, a 6 core, from what I gather from his post. Do you think this is what he is saying?

[Paul_Joy__UK_]

Good point, I'd missed that post. So there's at least one 5,1 12 core that's performing well which gives us hope in finding the difference.

Wil, are you using this machine fairly heavily?

I noticed that after experimenting with GPU's yesterday the performance was a lot better, but today I'm back in to editing decent sized projects again and my timelines are back to their previous laggy selves.

[Wil Renczes]

Correct - that's exactly what I'm saying.

I find that other thread interesting - what resolution are you guys running, and single or dual screen? In my case, I'm running with a older Cinema display, I think it's 1600 by 1080 or something like that (not in front of the machine right now).

Wil

[Paul_Joy__UK_]

I'm running a single apple 27" LED display @ 2560x1440

Reducing the screen res was one of the first things I tried, I didn't make any difference at all, although it was still with the same monitor connected.

This video from that other thread is very interesting as both macs are configured the same but one is a 3,1 with 22 gigs of Ram, the other is a 4,1 with 16 gigs.

The 4,1 is the laggy one, again it's the newer mac that's suffering. Although the fact that the clips are not displaying properly on the older mac when dragging does complicate matters. It's probably a driver or display issue but maybe that's part of the reason why it is so responsive, it's not having to render the opacity and details.

[LFedit]

I'm running a older 30" cinema display (2560 x 1600) and a 1920x1080 second display having the timeline on either display I find my performance starts to improve if my timeline uses less than 400px in height

[Paul_Joy__UK_]

Excellent find LFedit, it's the same here, big response improvement when reducing the height of the timeline. In fact I think I'd go as far as to say that you've found the root cause and will probably give Adobe a big pointer in the right direction.

Lets see what everyone else finds.

[LFedit]

I can't take credit for the find, Butch2oc found that one, and it really helped me out, so cheers to him.  Just wanted to chime in and see if we can get this sorted out.

[Wil Renczes]

Thanks guys, I think we can work with this.

[Paul_Joy__UK_]

Good stuff Wil.

Although it's a bit of an anti-climax to discover that the issue was discussed and reported back in April.  I hope we helped in some way to strengthen the case anyway.

[LFedit]

Just an update on the screen resolution fix, I just found that if the docked program, source, and project panels take up less than 400px and the timeline takes up the rest of the resolution the same speed increases apply.  I found it by using the maximize frame command and the timeline at full screen is super responsive, slowly start dragging it down, performance decreases.  Get outside of the 400px area, it lags horribly.  Can anyone replicate?

[Paul_Joy__UK_]

Yes, same here. Also the clips then become solid greys as in the video posted above. Good find, certainly appears to be some kind of display bug.

[LFedit]

Thanks for replicating Paul.

[jasonvp]

Paul Joy (UK) wrote:

Yes, same here. Also the clips then become solid greys as in the video posted above. Good find, certainly appears to be some kind of display bug.

OK, ignore my last post re: CPUs.  Cool, sounds like a potential win here.

Can someone make a quick clip showing how you're changing the timeline resolution and whatnot?  I'll be happy to test the lag out on my old 3,1 and post a response later.

jas

[Paul_Joy__UK_]

Thanks Jas, as requested.

[jasonvp]

Paul Joy (UK) wrote:

Thanks Jas, as requested.

I can reproduce this on my Mac Pro 3,1, all except for the last bit where you blow the timeline up to full screen and the video clip turns grey.  That doesn't actually happen for me.  The only thing that happens is: the larger I make the timeline window, the worse the lag gets.  Conversely the smaller I make the timeline window, the less lag there is.

Hope this helps.

jas

[LFedit]

Was just able to test this on a MacPro 3.1 and experience the same as Jason Van Patten.   No matter how the timeline is displayed I do not get the gray clip when dragging, and the larger the timeline window, including fullscreen the worse the lag. However, the lag on the Macpro 3.1 system is nowhere near as slow as it is on the 4.1.

[AtonMusic]

LFedit wrote:

Was just able to test this on a MacPro 3.1 and experience the same as Jason Van Patten.   No matter how the timeline is displayed I do not get the gray clip when dragging, and the larger the timeline window, including fullscreen the worse the lag. However, the lag on the Macpro 3.1 system is nowhere near as slow as it is on the 4.1.

Hi....

as said earlier I am experiencing the lag and that extremely.

Here are my system specs which are corresponding to what you are seeing on the 4.1 Model.

I am using PPRO on a 30" Inch Cinema Display... Perhaps that is worse that on a 15" inch LCD.

Hardware Overview:

  Model Name: Mac Pro

  Model Identifier: MacPro4,1

  Processor Name: Quad-Core Intel Xeon

  Processor Speed: 2.26 GHz

  Number Of Processors: 2

  Total Number Of Cores: 8

  L2 Cache (per core): 256 KB

  L3 Cache (per processor): 8 MB

  Memory: 32 GB

  Processor Interconnect Speed: 5.86 GT/s

  Boot ROM Version: MP41.0081.B07

  SMC Version (system): 1.39f5

  SMC Version (processor tray): 1.39f5

[Keith Moreau]

I think I've found the culprit, at least for me. The workaround is not the greatest but it's a clue for Adobe. It also doesn't match Paul's video #4, but it's another solution. In any sequence, if the the sequence timeline is smaller than a certain percentage of the whole screen, Premiere Pro will draw a reduced opacity version of the clip when dragging. This seems to cause the lag. If the timeline is made larger, maybe 60% or larger of the screen real estate, I can drag around with no delay. This includes not only dragging stuff within the sequence, but dragging clips back and forth from the project pane to the timeline. Everything is snappy and immediate. The reason is that when dragging, on this no-lag version, there is no drawing of a reduced opacity representation of the clip, it's just a gray outline. The dragging is without any lag. In the code, Adobe probably just 'gives up' at some number of total pixels needing to be redrawn and just says, "I'm just going to draw the outline, forget about the reduced opacity version of the clip.' However this results in snappy performance.

It's an example of a 'feature' that actually detrimental. If anybody knows of a way to 'turn this off' without having to manipulate the size of the sequence panel, please let me know. I don't necessarily like to have the sequence panel taking 60% of my 30" cinema display.

This doesn't match Paul's 'no lag' experience because I see in his screen recording part 4 that there is still a reduced opacity version of the clip when dragged, but perhaps this is due to other factors.

Also, for me it's 'total number of pixels', not percentage of screen, if I drag the sequence panel to my second, smaller monitor, I cannot get a 'non-lag version of the sequence, it always tries to render out the reduced opacity version of the clips and induces the drag.

However obviously there is something in the Premier Pro clip drawing code that is slow on Macs, and perhaps looking at the power of the hardware makes some decisions about how much to draw the reduced opacity version, making more powerful hardware actually seem slower. Having an Adobe software engineer repro this problem with some new Mac Hardware, 30" large screen would probably be able to solve it in a few hours.

Another poster who I private messaged with who had reported this problem to Adobe earlier this year and posted to another thread told me he just gave up and went to a Windows PC because it was much more responsive. I myself am tempted to do this, but I really, really don't want to go Windows / PC if I can at all help it. I'm sure that thousands of other former Final Cut 7 users are in the same boat so I think it behooves Adobe to fix this issue on Macs and make the choice easy for Mac users.

[Paul_Joy__UK_]

That would make sense Keith, it seems that the larger the area the timeline uses the more the code that handles the rendering of the timeline struggles. Although in my case this doesn't influence the CPU at all, my CPU usage stays the same regardless of the size of the timeline. This is true both with and without hardware MPE.

It does look like the code is triggering a failover and disables the clip drawing when the response slows down to a certain point.

Lets hope Wil and his colleagues can finish this little story on a high note.

[Keith Moreau]

Hi Paul

I realized that I posted pretty much exactly what you posted a few minutes earlier about the threshold, but didn't see your post while I was investigating and posting mine, there is some synchronicity going on here.

I did some further tests, and for me, in the laggy mode, there is pretty high CPU, in fact for me it easily pegs 100% on one CPU when dragging moderate to fast. When in the 'gray box' responsive mode, the CPU usage is quite a bit less, 25% to 50%. I didn't measure whether more lag equals more CPU, but I would suspect this might be the case, and if that Premiere Pro is using only 1 CPU thread, then it can only use up to 100% of one CPU, and when more is needed things just get slower. It just can't go faster than 100% usage.

It's also pretty easy to make a code sample in the Activity monitor of what Premiere Pro is doing, and there is seems that a lot of stuff is going on during a drag. An Adobe engineer could do this (they have better tools as well to analyze it) to find out what routine might be causing the high CPU usage. I don't think that a simple drag should take that much CPU.

I'm hoping that all this work on finding exact use cases will help Adobe determine the problem, I really want my Premiere on the Mac to be snappy!

Thanks to you and everybody for all the information and cooperation on this thread. I think the formula is lag = timelinepixels * motion

-Keith

[Paul_Joy__UK_]

Another thing to note is that you can also speed up the performance by reducing the width of the timeline, it seems to be that the smaller the area in general the faster it runs, that is until you hit the sounds barrier and get to turbo mode!

[Cutwithray]

I think I found another small bug that may be related to the Jerky timeline. I have found that when trying to drag clips around the timeline, if I want to drop it somewhere where there is a tool tip, it will not let. The tool tip needs to be out of the way im order to release the clip where you want it. I never really noticed that till today and think that is a bug. The code realted to that may be in play with the jerkyness?

Ray

[jasonvp]

Hmmmmmm.

Let's try another experiment if folks are interested: disabling CPU cores on a multi-processor 4,1 or 5,1 box.  I know this won't address those having problems with 3,1 or prior boxes, but play along here, please.

Find the CPUPalette.app in /Library/Application Support/HWPrefs

Once you fire it up, you'll see a graphical representation of each core.  For 2-processor machines, you'll have 2n cores (4-core x 2 processors = 8 cores, etc).

Let's try knocking one of the entire processors down and then restart PPro.  Clicking on a core (called 'CPU' in the app) will disable it.

Click on the last n cores, where n is the number of cores in EACH processor.  So if each processor in your machine has 6 cores, meaning you have a 12-core box, then click on the last 6 cores.  That'll disable the entire processor.  Once you've done that, fire PPro up again and give the black vid test another go.

Don't forget to re-enable the cores when you're done.

jas

[lasvideo]

Ive noticed that same trend as well. Its the first time I am glad that I have an older computer.