*huge* CPU load for animated selection border;v1.5.0.39

[anonymous]

Tested v1.5.0.39 on Windows Server 2008 R2 x64 (via RDP) with 10 cpu cores and >24 GB RAM.

 

Steps to reproduce:

 

1. create a blank image

2. make sure "View" -> "Show Pixel Selection" is checked (BTW: missing german translation: should be "Auswahl anzeigen")

3. select some area

4. wait 20 seconds

5. see huge CPU load (30% - 50%) in taskmanager

6. uncheck "View" -> "Show Pixel Selection"

7. wait 20 seconds

8. see normal (=0) CPU load

 

May be the issue is not directly related to Affinity Photo and has its root cause in RDP. But even then a CPU load of at least 30% (up to 50%) of a 10-core-machine for only animating lines seems to me like a bug and prevents Affinity Photo from being used remotely. GIMP and Adobe therefore have the option to change the animated selection to a non-animated one. This is what i also suggest for Affinity Photo: It would be nice, if the option "Show Pixel Selection" could be changed to "Animate Pixel Selection" (german: "animierte Auswahl"). This would remove a show-stopper for introducing Photo in our company.

 

(BTW: I doubt that fully hiding the selection can be beneficial at all.)

[jullit31]

I cannot reproduce this on my Win 10 pro quad-core 16 GB RAM machine:

 

1. create a blank image

2. make sure "View" -> "Show Pixel Selection" is checked

3. select some area -> instantly 12% CPU load @ 1.5 GHz

4. wait 20 seconds

5. no change

6. uncheck "View" -> "Show Pixel Selection" -> instantly 4% CPU load @ 0.9 GHz

7. wait 20 seconds

8. no change

 

Maybe this problem is specific for Server 2008 R2...

[anonymous]

I cannot reproduce this on my Win 10 pro quad-core 16 GB RAM machine:

3. select some area -> instantly 12% CPU load @ 1.5 GHz

6. uncheck "View" -> "Show Pixel Selection" -> instantly 4% CPU load @ 0.9 GHz

 

1. If I  get you right, you DID see an unsusually high impact on CPU (12% drops down to 4%)

 

2. did you really try this via RDP from another machine?

(if not try: "mstsc /v <your_remote_client_name_or_ip>" on console)

[jullit31]

1. Yes, I did, but not with a 20 second delay and by far not as severe (something that causes 30% - 50% load on your CPU would probably lead to 100% on mine).

 

2. No, but I did now: Same principal behaviour, just a bit worse (16% when showing the selection and 5% otherwise). So for you this only happens when using RDP?

[anonymous]

1. Yes, I did, but not with a 20 second delay and by far not as severe (something that causes 30% - 50% load on your CPU would probably lead to 100% on mine).

 

2. No, but I did now: Same principal behaviour, just a bit worse (16% when showing the selection and 5% otherwise). So for you this only happens when using RDP?

 

1. The step to wait 20 seconds was only to be sure the full CPU useage appears. I did *not* experience a delay. In my case a large increase (to about 30%) appeared instantly. And then a further slow increase to about 50% appeared in the next 10-15 seconds.

 

2. ATM I can only test via RDP. I'll try to test bare metal as soon as i can and report here.

[anonymous]

2. ATM I can only test via RDP. I'll try to test bare metal as soon as i can and report here.

 

Now tested without RDP. Same problem still exists.

[Henry Stahle]

No huge CPU load.

 

I cannot reproduce this on my Win 10 pro quad-core 16 GB RAM machine. I just tested this. My CPU raised from 0% to 6.8 %... after "View" -> "Show Pixel Selection". It went back to 0% after unchecking "Show Pixel Selection"...​ I use System Mechanic and maybe that explains the low impact on my CPU..?

[Mark Ingram]

I just tested this on my desktop machine via RDP which is a 6-core Xeon machine, and the CPU usage was at 0.1%.

 

Is your renderer set to WARP? As that would do the rendering on CPU rather than GPU, which might explain some of the high usage.

[anonymous]

In Edit -> Settings -> Performance i can read "WARP" but have no other choice.

See attached screenshot.

[anonymous]

<screenshot>

[anonymous]

Problem still exists with latest beta. Is there any possibility to test latest rc without buying it? I'd like to test a demo version to see this bug fixed before paying money for a product.

[Mark Ingram]

Problem still exists with latest beta. Is there any possibility to test latest rc without buying it? I'd like to test a demo version to see this bug fixed before paying money for a product.

 

It looks like we can't detect your graphics card, so it's falling back to WARP. I'm not entirely sure how the application has correctly started without a graphics card. What is your GPU?

[anonymous]

device manager says:

 

"VMware SVGA 3D"

[Mark Ingram]

device manager says:

 

"VMware SVGA 3D"

 

Hi, we don't support virtual machine installations, exactly for reasons like this. You're free to use it on a virtual machine if you wish, but without a decent graphics driver, you will end up using WARP which is a software emulation of a GPU, hence the high CPU usage.

[anonymous]

Ok. So far, so good.

 

But doesn't this huge CPU load point to an error in the implementation of the WARP software emulation? I can't imagine why drawing a dashed line should be this cpu intense - even in software emulated mode.

 

Will you implement the suggested option to change the animated dashed line to a non-animated one in future releases? (This is the last show stopper preventing us from buying the software, as we only have VMs in our company.)

[Mark Ingram]

Ok. So far, so good.

 

But doesn't this huge CPU load point to an error in the implementation of the WARP software emulation? I can't imagine why drawing a dashed line should be this cpu intense - even in software emulated mode.

 

Will you implement the suggested option to change the animated dashed line to a non-animated one in future releases? (This is the last show stopper preventing us from buying the software, as we only have VMs in our company.)

 

No, WARP is a highly performant software rasteriser (this is a Microsoft technology, not something we've implemented). It's rendering pixel shaders at 60fps on the CPU. I think it's pretty impressive that it's "only" using 30%-50% CPU.

 

I could possibly add something to disable animated marching ants if the renderer is set to WARP. The only problem is, there are lots of other things that need fixing or implementing, and with a small team, other things will often have a higher priority. How many people are in the company? What's the reason you only use VMs?

[anonymous]

No, WARP is a highly performant software rasteriser (this is a Microsoft technology, not something we've implemented). It's rendering pixel shaders at 60fps on the CPU. I think it's pretty impressive that it's "only" using 30%-50% CPU.

 

OK, I understand. I indeet thought WARP was implemented by you.

[anonymous]

I could possibly add something to disable animated marching ants if the renderer is set to WARP. The only problem is, there are lots of other things that need fixing or implementing, and with a small team, other things will often have a higher priority.

 

It would be great if you could add an option to disable the animation. Other Software (GIMP, PS) also provide such a feature.

I fully understand that this "problem" is not on top of your list. For the moment it is enough for me to know, that you are willing to implement it in the future. So i keep monitoring the progress of your software. It would be great, if you could leave a post here, if it is done.

[anonymous]

How many people are in the company? What's the reason you only use VMs?

 

We are about 170 spread over 6 different locations. People also switch between locations as the workload requires. And they need "their" software, settings, data etc. wherever they log in to the system. Keeping software, patches, settings, data etc. up-to-date on each single hardware machine was a PITA in the past. So we decided to switch over to a Terminal-Server-VM some years ago where all employees work on one single machine. This was the best decision we could do and we can not revert this because of one software.

 

For the future we plan to put GPUs into the VM-nodes so that VMs also benefit from GPU-powered rendering. But ATM we have none.

[anonymous]

On 21.12.2016 at 11:28 AM, Mark Ingram said:

I could possibly add something to disable animated marching ants if the renderer is set to WARP. The only problem is, there are lots of other things that need fixing or implementing, and with a small team, other things will often have a higher priority.

Any news on this?

[Mark Ingram]

34 minutes ago, anonymous said:

Any news on this?

 

Hi, no, not yet.

[anonymous]

On 12/21/2016 at 11:28 AM, Mark Ingram said:

I could possibly add something to disable animated marching ants if the renderer is set to WARP. The only problem is, there are lots of other things that need fixing or implementing, and with a small team, other things will often have a higher priority.

Has some progress been made in the meantime?

[Mark Ingram]

58 minutes ago, anonymous said:

Has some progress been made in the meantime?

There have been plenty of performance improvements in recent (customer beta) patches, but no work has been made on supporting VMs, or improving the performance of Microsoft's WARP renderer. Unfortunately it's not high enough priority to work on it, given all the other work we have. We're a small team, so we have to choose to fix bugs / add features / improve performance in the areas that affect the majority of our customers (or potential customers). Apologies for this, I appreciate it might not be what you wanted to hear...

 

[anonymous]

On 3/6/2019 at 11:01 AM, Mark Ingram said:

Apologies for this, I appreciate it might not be what you wanted to hear...

 

Right. ;-)

I didn't expect you to fully support VMs or even to fix WARP. I only hoped for an option that lets me choose if a selection is represented by fixed dashed lines instead of animated marching ants.