Manipulation

[Baton]

Hi everyone,

I am still a V1 user and I am testing V2 versions. In both programs I often use the duplicate function. After I select object(s), I use shortcuts Ctr and in combination with Shift key and move them. I Publisher V1 works this function(s) quite gut and smooth. Unfortunately, not any more in V2, especially with combination Ctr+Shift+ moving the selected object(s) with the left mouse button. It's act with a delay, very slow, often 'freezes' for a few seconds. The moving is abrupt, not smooth.

Computer configuration is quite good: i5-12400F, NVIDIA 3060Ti 8 MB, 32 GB RAM, SSD 512 GB (M.2)

[4dimage]

Did you try to turn of hardware acceleration in the app performance preferences?

[Baton]

No, not I wrote this message before. I have checked it now. Still the same result(s).

Previosly I have done with tables. No I have tried with smaller and single object(s). And works good.

I have attached this one side I worked on but catalogue ca. 80 sides. I'm working on all sides opened from PDF-file in the orginal.

table manipulation example.afpub

[Baton]

When I'm working now with only this one side, everything works smoothly and correctly.

Noo I can see.

This means that working with larger files and more complex projects causes problems for the program.

[4dimage]

Tried your onepager. Guess the response when starting a normal drag with repositioning is quite normal.

Duplicating the rather complex table structure of course needs more internal computation before starting the drag operation.

Drag + CTRL has a significant delay (on my machine about 500-1000 ms). But due to the complexity of the table this may to be expected and seems to be acceptable.

EDIT

If i duplicate this table some times, so that the page fills up with more and more Objects the delay becomes more sigificant and draging around is very "slipery"?

Meaning every change of position during the drag phase has a significant delay.

This seems to be related to active snapping. Depending on your snapping settings the number of possible snapping candidates grows with the number of objects in your page. If you turn off snapping temporarily draging is a lot more fluid. The more snapping candidates the more internal computation.

 

Also grouping of objects reduces the snapping candidates depending on your snapping settings. In your example file all objects (385) sit ungrouped in the top level of the page. So every single Object is checked as a possible snapping candidate during drag drop.

 

My machine: Windows 10 Pro for Workstations (22H2, 19045.2251, Windows Feature Experience Pack 120.2212.4180.0), 8 core Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz, 64 GB RAM, NVIDIA Quadro P4000 (driver 512.78), 2 x 1GB SSD

[Baton]

On a singe page, like in exaple, works good.

After grouping even better with the same snaping settings.

But with 176 pages, after grouping and changed snaping settig, delay is clearly visible.

[4dimage]

Weird 🤔 Feels as if snapping search does not stop on the actual active page but is looking for candidates on all other pages too ?

[Baton]

Yes. The behavior of program is a little strange. I have changed the settings of snaping and the result is still the same. The problem may be inside of code, I suppose.

I don't believe that anyone could works on bigger projects in InDesigne. Let's wait for new update or best version. I hope meny bux reported by users will be fixed in all programs.

[4dimage]

EDIT: see annotations below !

 

OK, just for my own interest i did the follwing test with your onepager file.

- I set the document page model to facing pages

- I duplicated the inital page 149 times to get 150 pages.

- My snapping uses all candidates. All options are ticked. Snapping is active.

Unforunately i can not reproduce such strong delays when draging around a selected table on one page or duplicate it with CTRL + drag. There is only some shorter delay on drag start (500+ ms). There is only a small delay difference between snapping off and on as long as there are not too much objects on the same page or on the facing page beneath.

Of course i don't know if your original document contains much more objets like images and much more complex tables.

Maybe your machine lacks of enough resources (CPU, RAM) for such huge documents?

Can anyone help out with some experience on the book functionality and|or dividing a big multipager into smaller chunks|documents ?

Cheers.

 

EDIT

Sorry - should have done the duplicate test at the end. Now i can reproduce the missbehaviour.

- I select a table group e.g. on page 10/11

- I start drag with CTRL hold to duplicate the selected Objects

- Publisher freezes

 

After about 30-60 Seconds Publisher recovers and the duplicated Objects are shown on the drop position

 

This behaviour occours no matter on which page i initialize the CTRL+ drag, or if snapping is completely on or off, or hardware acceleration is on or off.

After some waiting time Publisher recovers and one can drag the duplicate objects arround without sigificant delay.

But the next attempt to duplicate with CTRL + drag reproduces the exact same behaviour: Publisher freezes again for 30-60 seconds and recovers again.

 

If you duplicate the selected objects via keyboard shortcut CTRL+J there is also a sigificant response delay about 4-6 seconds until you can shift away the duplicates via arrow keys or mouse drag. So there is also a small freeze period before you can interact with the duplicated objects.

 

This is some task manager history during the drag drop freeze phase:

 

 

 

 

[Callum]

Hi All

I can't seem to recreate this here with the single page document which I understand is the case for both of you, If this is only occurring once there is already a high number of objects in your document then its likely that this is to be expected I'm afraid as the app isn't crashing its just getting slower as hardware consumption goes up. If the app starts crashing completely or this occurs when working with just a single page please let me know.

Thanks
C

[4dimage]

@Callum

5 hours ago, Callum said:

If this is only occurring once there is already a high number of objects in your document then its likely that this is to be expected I'm afraid as the app isn't crashing its just getting slower as hardware consumption goes up. If the app starts crashing completely or this occurs when working with just a single page please let me know.

Wow i'm just stunned - and that's it ? ...................... to put i politely: "I am not amused" !

"Oh, if it works with one or two pages we are all happy - Kumbaya..."

Do not take it personally, but that's .......................................

 

1) First of all: Batons document scenario is nothing unusual for professional graphic designers. Create a "boring" product catalogue with hundreds of pages and complex technical tables and CAD drawings. Not sexy - but often that's our daily bread. And we need performant and reliable tools to get our work done!

 

2) Didn't you see my specs ??? I guess my machine is beefy enough to handle bigger tasks (8 Core Xeon, 64 G RAM, dedicated graphics card,...). And as the above screenshot of my task manager showed: during the 30-60 freeze period there was only max. 10% CPU / 2 GB RAM usage.

So don't blame it on the hardware consumption!

 

3) I recreated a similar document with Batons original graphics in InDesign CS6. Note that this (32 Bit) software now is far over 10 years old and was never intended to work on Windows 10. This test is done on the exact same workstation as the above Affinity Publisher test. Exact same environment, real time. And the objects are NOT embedded PDF files - these are all editable InDesign text and mostly vector objects duplicated on each page. And object snapping is on!

As you can see in the first video i copied the objects from the first page over and over into th other pages (CTRL c -> ALT+SHIFT+CTRL v). I repeated this 74 times. As you can see in the task manager the CPU usage varies around 5-10%. And sometimes there is a little delay (1-2 sec) when pasting or scrolling. Yes, so much objects on so much pages. But at the end the whole documents keeps stable and the work can be robustly saved.

In the second video you can see that it's still possible to drag around and copy groups of elements in this huge document. Either with CTRL c/v or ALT+drag. It's even possible to drag copy the elements onto other pages - meaning draging and scrolling in this huge document at the same time time! And again - object snapping is active!

Yes, there are sometimes delays of 1-2 seconds on ALT-drag. But this might be expected. Compare this to the Affinity Publisher case described above where the whole application freezes for 30-60 seconds on EACH CTRL+drag !

Important side note: InDesign seems to be aware of the heavy task and only shows the bounding box of the moved elements during dragdrop. Small but important detail to increase interactive performance. One of the simplest, most effective and oldest strategies i have experienced since i work with several DTP software over decades. It just works!

I started with Affinity arround 2017 and always hoping for the best. But this bugy release 2.0.0 has really disappointed me 😔

The fundamental question with the Affinity Apps is: Is Serif really willing to sometime provide professional software for professional users?

Or do you rather like to stuck in your niche with "cute small documents" and "cute small illustrations"...

 

P.S. ... and by the way just for the records:

This is how it looks like in Publisher with Batons original document. There is only ONE page and i have snapping on. I CTRL+drag the table elements around. See how laggy this is even with one single page. And watch the hardware consumption (CPU / GPU) of your "state of the art" 64 Bit software compared to the above "mature" 32 Bit InDesign 🙄

 

 

[Callum]

I decided to take another look at this issue with our QA team and while they initially echoed my above statement I decided to test this against Publisher V1 and found it did perform slightly better than V2 I believe there is room for improvement here so I have logged this with our development team to see what they can do.

Thanks
C

[Baton]

On 12/7/2022 at 2:56 PM, 4dimage said:

@Callum

Wow i'm just stunned - and that's it ? ...................... to put i politely: "I am not amused" !

"Oh, if it works with one or two pages we are all happy - Kumbaya..."

Do not take it personally, but that's .......................................

 

1) First of all: Batons document scenario is nothing unusual for professional graphic designers. Create a "boring" product catalogue with hundreds of pages and complex technical tables and CAD drawings. Not sexy - but often that's our daily bread. And we need performant and reliable tools to get our work done!

 

2) Didn't you see my specs ??? I guess my machine is beefy enough to handle bigger tasks (8 Core Xeon, 64 G RAM, dedicated graphics card,...). And as the above screenshot of my task manager showed: during the 30-60 freeze period there was only max. 10% CPU / 2 GB RAM usage.

So don't blame it on the hardware consumption!

 

3) I recreated a similar document with Batons original graphics in InDesign CS6. Note that this (32 Bit) software now is far over 10 years old and was never intended to work on Windows 10. This test is done on the exact same workstation as the above Affinity Publisher test. Exact same environment, real time. And the objects are NOT embedded PDF files - these are all editable InDesign text and mostly vector objects duplicated on each page. And object snapping is on!

As you can see in the first video i copied the objects from the first page over and over into th other pages (CTRL c -> ALT+SHIFT+CTRL v). I repeated this 74 times. As you can see in the task manager the CPU usage varies around 5-10%. And sometimes there is a little delay (1-2 sec) when pasting or scrolling. Yes, so much objects on so much pages. But at the end the whole documents keeps stable and the work can be robustly saved.

 

In the second video you can see that it's still possible to drag around and copy groups of elements in this huge document. Either with CTRL c/v or ALT+drag. It's even possible to drag copy the elements onto other pages - meaning draging and scrolling in this huge document at the same time time! And again - object snapping is active!

Yes, there are sometimes delays of 1-2 seconds on ALT-drag. But this might be expected. Compare this to the Affinity Publisher case described above where the whole application freezes for 30-60 seconds on EACH CTRL+drag !

Important side note: InDesign seems to be aware of the heavy task and only shows the bounding box of the moved elements during dragdrop. Small but important detail to increase interactive performance. One of the simplest, most effective and oldest strategies i have experienced since i work with several DTP software over decades. It just works!

 

I started with Affinity arround 2017 and always hoping for the best. But this bugy release 2.0.0 has really disappointed me 😔

The fundamental question with the Affinity Apps is: Is Serif really willing to sometime provide professional software for professional users?

Or do you rather like to stuck in your niche with "cute small documents" and "cute small illustrations"...

 

P.S. ... and by the way just for the records:

This is how it looks like in Publisher with Batons original document. There is only ONE page and i have snapping on. I CTRL+drag the table elements around. See how laggy this is even with one single page. And watch the hardware consumption (CPU / GPU) of your "state of the art" 64 Bit software compared to the above "mature" 32 Bit InDesign 🙄

 

 

 

Thanks a lot 4dimage.
Quite an interesting lecture and presentation, but I think it is neither your job nor for you to explain the problems of the program system resources consum.