There seem to be several performance issues in the past rapid set of releases. If you could attach the latest DxDiag results here, maybe we could help ensure that things are running smoothly. For example, was there a reason your iGPU was disabled, and would you want it operational again?

Quote There seem to be several performance issues in the past rapid set of releases. If you could attach the latest DxDiag results here, maybe we could help ensure that things are running smoothly. For example, was there a reason your iGPU was disabled, and would you want it operational again?

I'm beginning to think this is a PD problem more than my computer's problem, which is disappointing. Maybe they will fix it? I'm new to this software so I'm unsure of how good they are at listening to consumers.

I disabled the Intel GPU so that PD (and everything else) would run off the NVIDIA GPU. This was based on some research I did online to attempt to improve the performance of PD. (Spoiler: didn't quite work although it does seem slightly better)

Are there specific parts of the DxDiag that are more important than others? This is a semi-public forum and I'm not entirely comfortable with dumping the full contents onto the internet. To be fair, I'm not sure of what content is in DxDiag in totality. But I would prefer not to be hacked.

This is a fully public forum (no privacy whatsoever), but there's nothing sensitive in the DxDiag data. If it makes you feel better, delete the Machine ID tag near the top which is unique to that computer before attaching the text file here. Everything else is hardware specifics, software versions and settings.

While there are times when you might want to disable hardware encoding and/or decoding from within PD, there's no reason I'm aware of to intentionally disable any GPU in Windows itself.

I believe that newer versions of PD are able to use different GPUs for different timeline tasks to improve editing performance, but you'll always need to choose one (or none) specifically when producing. You can easily force PD to use either the Power saving or High performance GPU on a per-app basis from the Start | System | Display | Graphics menu. The default is to let Windows decide.

Quote This is a fully public forum (no privacy whatsoever), but there's nothing sensitive in the DxDiag data. If it makes you feel better, delete the Machine ID tag near the top which is unique to that computer before attaching the text file here. Everything else is hardware specifics, software versions and settings.

While there are times when you might want to disable hardware encoding and/or decoding from within PD, there's no reason I'm aware of to intentionally disable any GPU in Windows itself.

I believe that newer versions of PD are able to use different GPUs for different timeline tasks to improve editing performance, but you'll always need to choose one (or none) specifically when producing. You can easily force PD to use either the Power saving or High performance GPU on a per-app basis from the Start | System | Display | Graphics menu. The default is to let Windows decide.

Thanks for your feedback! Based on your comment, I went and re-enabled the OOTB GPU (Intel(R) UHD Graphics 630). Did not see a change in PD's performance. Still a turtle - particularly with the PiPs on first start up as they download from the cloud.

I re-ran DxDiag. Interestingly, the Intel GPU now lists 2nd in DxDiag. See Attached.

I did remove some of the details in DxDiag - well, until I got bored. I didn't see anything obvious going on within it, and I'm willing to accept that this is a fault/flaw CyberLink has created within its software. I hope they fix it - but I am not overly optimistic about that.

I used to work in tech - unraveling an architectural change within software is a challenge. I'm fairly certain that's what they've done - PiPs are now stored in the cloud and downloaded locally upon startup of the software. (This is a dumb architectural decision - there are better ways to have software receive content. Those ways are more complex (pull is harder than push) and take longer to implement, but they don't create a performance issue unless the user is requesting the download.) Heck, other features and components that run BTS may be stored in the cloud now as well. Their best hope is to try to do whatever they can to improve latency with their communications between the local clients and their craptastic cloud. (This probably means they need to pay more $$ to their cloud provider. Like, a lot more.)

I digress. Please see the attached DxDiag_Enabled.txt.

Very intersting observations, but I don't think PIPs have been moved to the cloud. I say that because my desktop can't currently reach the CL cloud at all, yet all my resources eventually show up. I even turned off the Wi-Fi connection and still watched the titles slowly populate, so the sluggishness is happening when loading local resources. As you noted this is new behavior.

Something that used to be done in a couple of seconds now takes almost a minute, and that's on a system with a CPU Passmark score almost 4x higher than yours That's clearly a design issue (aka bug) and CL will need to address it.

Back to your iGPU. I suggest updating the video driver as the installed version is 2.5 years old. You can use the automated tool from the Intel support site to get the latest and greatest installed, or download it manually from here. I doubt that will have any major impact on the overall sluggishness but it may help in specific editing cases.

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

Quote Very intersting observations, but I don't think PIPs have been moved to the cloud. I say that because my desktop can't currently reach the CL cloud at all, yet all my resources eventually show up. I even turned off the Wi-Fi connection and still watched the titles slowly populate, so the sluggishness is happening when loading local resources. As you noted this is new behavior.

That's interesting - no WiFi and they still loaded. My original thought was that the PiP cloud is a different cloud than the userbase CL cloud, but you had no WiFi at all. This makes me wonder where they are being stored, and why it is taking so darn long for them to load/cache, and why that load must happen each time PD launches. The theories behind why that would happen are just depressing, so I'll just pretend they'll fix it someday.

Quote Back to your iGPU. I suggest updating the video driver as the installed version is 2.5 years old. You can use the automated tool from the Intel support site to get the latest and greatest installed, or download it manually from here. I doubt that will have any major impact on the overall sluggishness but it may help in specific editing cases.

This I definitely can do - thanks for the suggestion!

Please post back if you see any improvements!

Meanwhile I'll see if I can figure out a little more about the sluggish loading issue and will also submit a support ticket. The more people reporting issues and the more details they provide should give CL enough info to act.

Quote

That's interesting - no WiFi and they still loaded.

Hi,

I have tested this in a similar way.
5 days ago I noted the following, on my system with 650 titles, 573 effects, 1069 PiP objects and 190 particles it takes about 45 secs before PDR "normalises".

Today, it took the same with, or without, ethernet connection.

So, if there is no external download required, and only internal local loading, and taking into account the comments of others on widely different "loading" times, the duration of loading would probably be more dependent on system spec and performance than anything else?

Cheers
PowerDirector Moderator

For customer support related issues, please contact:
- Customer service: https://membership.cyberlink.com/support/customer-services.do
- Technical support: https://membership.cyberlink.com/support/service/technical-support.do

Quote


Hi,

I have tested this in a similar way.
5 days ago I noted the following, on my system with 650 titles, 573 effects, 1069 PiP objects and 190 particles it takes about 45 secs before PDR "normalises".

Today, it took the same with, or without, ethernet connection.

So, if there is no external download required, and only internal local loading, and taking into account the comments of others on widely different "loading" times, the duration of loading would probably be more dependent on system spec and performance than anything else?

Cheers
PowerDirector Moderator

Well, IMHO - that is a yes and a no.

Yes to the duration of sluggishness being system dependent. It will be less slow for higher performing systems.

No to the sluggishness being wholly dependent upon the system. Unsure if you are implying that or not?
Benchmark standards within IT would gasp, choke and faint at a 45 second delay before software is usable by a front end user.

As optodata mentioned earlier, their system has a better GPU than my own and their system is also slow. For whatever reason, the PiPs, their metadata and their thumbnails are cold-loading each time upon the startup of PD. I just confirmed the same cold-load behavior exists with Transitions, fX, Particles, but as there are less of them than PiPs - perhaps their load time isn't as noticable. This did not appear to be happening in earlier versions. If it was, the load was noticably quicker.

This PiP issue is one of a few performance issues I've noticed - the others being a lag with the right-click menu, and severe lag in clicking upon PiPs in the timeline to have them activate. The PiP Editor also takes much longer to load. And the timeline can flake out. I've had two audio clips on the timeline completely lose their reference file. (I might own up on the last one as a bizarre user error though - that was a tough edit.)

From Jan until around the March timeframe, I did not have these issues. I'm in this software almost daily. The performance has gotten to the point where I'm frustrated using this software - which is why I am came here to this forum seeking wisdom from the greater community. (And I have received it - I now know I'm not alone in this issue, and I should update my iGPU driver. Thanks optodata!)

ETA: Response Time Limits <-- This URL is a 2010 update from a 1993 article - still lists the same timings - which are based on 40 year old research done by human factors engineers. These timings apply to web-based applications as well as client-based applications. Web-based performance was an issue in the past because users expected (demanded, really) the instantaneous behavior they saw in thick client applications. (Yeah, I had to add this - cuz that's just how I roll.)

I agree that the issue doesn't seem to have much, if any, relevance to the system/CPU/GPU processing power. I made this screen recording a week ago but have just now completed the notation and highlights to showcase the two main issues here:



For the record, I have 698 titles, 784 Fx, 1115 PiPs and 221 particles and it takes 53 seconds to "normalize."

As shown in the video, the Search function cannot be used because any typed text is continually overridden by the constantly refreshing Search the library text. In addition, it often takes 2 or more mouse clicks on many menu items before PDR actually registers them and responds.

PDM can you pass this thread on to your CL contact? Would it help if I submitted a support ticket referencing this thread as well?

Quote
PDM can you pass this thread on to your CL contact? Would it help if I submitted a support ticket referencing this thread as well?

PDM - if there is something you can do to address this on your end, it would be appreciated.

My ticket is CS002505399. It's still open. My most recent communication in that ticket added a reference to this thread, but if you have a way to get that ticket past Tier 1 support and over to Tier 3, I think that would help.

My assumption, based on the monthly releases PD is doing, is that CL PD development runs some flavor of Agile/SCRUM. Which means this issue just needs to be added to the developers' backlog. That will allow the issue to be prioritized properly by the right folks in sprint planning, and eventually picked up in one of their upcoming release cycles/sprints for deployment into a monthly update.

If there's a better way to draw attention to this so that eventually winds up in the developers' hands, by all means, let us know! I'm willing to do whatever is needed to get this to the right folks.

We end users just want this performance issue resolved.

Quote


PDM - if there is something you can do to address this on your end, it would be appreciated.

Hi,
Sorry about the delay. Our latest information is that CL are aware of the issue and are currently working to implement a solution to increase performance in the loading of the content available to download. As of today, we have no details of a fix release date but we are given to understand it is already actively being developed.

As soon as we are aware of anything further we'll post it here and/or as an update notice.

Cheers,
PowerDirector Moderator

For customer support related issues, please contact:
- Customer service: https://membership.cyberlink.com/support/customer-services.do
- Technical support: https://membership.cyberlink.com/support/service/technical-support.do