Ronald N. Tan

Just to reply as a form of solidarity and voting for the proper and full support of RTL languages, especially Arabic and Farsi. I am currently learning Farsi for the purpose of culinary purposes and as mentioned previously and many...many times...Serif needs to somehow add Arabic, Farsi, Hebrew, Urdu as these are the major Middle Eastern languages with potential to poach users away from Adobe products. My Hindi Devanagari is stronger than my Farsi. I've expressed my disappointment with the lack of proper Indic languages in Affinity trio of products. Indic languages are LTR and should be "more easier" to adapt and implement than RTL. I have to use the Glyph Browser and fix certain merging of Hindi alphabets (as an example). When entering Farsi, say for typing out names of Persian Food, I have to use the glyph and find the specific glyph that corresponds with the alphabet's position. It's cumbersome, but for my use (and needs), it is a band-aid fix. If not for version 1.X, I and many others who are of RTL and LTR languages would like to have this in version 2. Heck, maybe raise the price a little bit. Even with a few raise in price, still BEATS renting software from Adobe!!!

I have no idea what those are. I am hoping Serif might find those files and have some kind of leads. Since my last post reply, I was working on entering glyphs of Persian (Farsi) words manually. I haven't had any document loading oddities. Fingers crossed that the oddity doesn't present itself anytime soon.

No crashes thus far. At the moment, I am fixing up my margins and all that alignments. This requires me to open each AP Template file, fix my margins, and export (save) as AP Template to override the old template file. Then, any documents that uses that template has to be fixed. As you can see and from my initial reporting, this oddity can't be predicted. It happens sporadically. I was hoping the dump files from prior crashes might offer some kind of clues.

I was not able to induce or have the "Document loading" crash yesterday. I can't tell if, disabling OpenCL did worked or because my AP template files are on the C-drive (as opposed to my Z-drive which is an internal HDD drive). Did anything gathered or helped clued as to what was causing the "Loading document" freeze? I have re-enabled OpenCL and moved my template files back onto the Z-drive.

Just in case...here are all 14 AP dump files that are related to this oddity I am reporting in this thread. Almost always, the "crash" is more or less induced by the user to force close the AP app, when it hangs/stuck/freezes on "Opening 1 document" when working with AP Template files and documents that are made from AP Template files. I included the AP Template files I made for my sole purpose of using AP for making slides and collages for uploading to Instagram and social media purposes. There are three main folders: Collage, IG Post, and IG Story. If you need to inspect to see anything for further investigating, check my Collages folder for various AP Templates I made for collaging purposes. I don't think I did anything wrong. It only only margins with specific values and empty image place holders at various positions throughout the document. Tomorrow the 9th, I'll update with anything or new crash dumps from having OpenCL off and moving the templates files directly onto C-drive. 911a0103-a89e-423d-95d6-cfc7411f47c1.dmp 9f19541d-d216-4d5a-b670-a03edee7665f.dmp 34ae1179-5d8a-41ae-bae3-59026ce973ff.dmp 411408ef-45fd-4e5c-9a1f-7a40faf512da.dmp 45e57abd-1f95-4fbe-83bd-619292e32b31.dmp 180ed72a-d58a-40d5-ba85-49678175c99c.dmp 7391f454-38f6-4ed9-9438-5707a9152bc8.dmp 2e17b894-6fd2-4154-ba51-c7b1fbb498b8.dmp 41923ecd-2d5b-416c-a65a-cad2741981fb.dmp cad1e9c0-5b9f-4ccb-b1c1-af5414f8ac1e.dmp ed149463-4f17-4805-a198-11507fcb912c.dmp 0b000af4-c21f-487b-ba67-4337f2d2ef19.dmp 0e76e815-ebb6-41c3-9fe2-6ed98e0bd2af.dmp dab6105e-ef18-4088-bb41-e8347dfd63f9.dmp Publisher Templates (Test).zip

Also, these files are from that oddity that occurred on the 7th. There are 14 files like this in the %AppData%\Affinity\Publisher\1.0\CrashReports\reports. Attached are the recently three crash dumps. 911a0103-a89e-423d-95d6-cfc7411f47c1.dmp 9f19541d-d216-4d5a-b670-a03edee7665f.dmp 34ae1179-5d8a-41ae-bae3-59026ce973ff.dmp

Hi Dan, For today 8th April, I have disabled openCL in AP and have moved all my templates folder to a test folder directly on my C-drive, which is a Samsung PM991a NVMe 512 GB. I will purposefully see if I can stress my usual working condition to see, if I can make the crash more predictable and will try to capture the dump files for Serif to determine, if further testing is needed.

I updated to the latest available drivers as per your suggestion. This is the oddity part. There was a .aftemplate file that I created and used. I made changes and fixed font sizes here and there. It was working. I made a few more changes and I was about to final export to upload to my Instagram and the freeze occurs. I was trying to screen record, but it happens random and I can't predict or have conditions narrow down to repeat with more consistency. As I mentioned in my OP, when the long time of "Loading document...." happens, clicking anywhere results in a force clousure and debug information and etc are sent to Microsoft message appears. After that, I reload AP and I could access and open that file like a snap. Where does AP store the dump file? Will sending you that dump file help you and Serif see any information or clues what might be causing this oddity?

The only way I use Publisher is making graphical and text posts for carousel for Instagram. This oddity happens when I open a single document, e.g. templates to make collages, if that make sense. I included a screenshot of my Templates I made. They are saved in a folder and this folder is referenced/seen in AP. The "X" you see are sized pictures frame placeholders for me to place my images was File and Place commands and the images are always in embedded and never linked. These templates are stored on my internal HDD. Z:\Collage Templates. "Z" is the name and drive letter designation of my internal HDD.

I am not sure, if my example is an isolated case or something to look into...I am finding lately that the recent Publisher 1.10.5.1342 would be stuck/frozen at "Document Loading...." Clicking anywhere on the screen would force Windows 11 Home to close AP and upon restart, the document would load OK or if not, I would have to force close and finally it would open successfully. To me, these happen—albeit somewhat unpredictable—when loading documents saved as templates. I like to do collages of gridded image displays. These template files are only in the KBs in size. Something wonky is happening. My PC is a Dell XPS 8940 shipped in February 2022.

I know from trialing out Affinity Photo (AP) that I can manually fine tune slices and/or have the layers into slices. What about the ability, where the user can—via single click operation—to have the guides in an image to made into slices or later exporting as individual slides? This is similar to Photoshop's ability to make the guides turn into slices, which can be later exported as separate slices. It's a one-click operation. Thoughts? Feedback?

Just replying here as a vote for this much needed ability. Indic languages are LTR, which should be in the priority or if not already being tested internally by Serif. I could understand, if Serif faces RTL, e.g. Arabic, Farsi (Persian), etc. Plus, with India's population of potential Serif products adoptees, it's no brainer that having Devanagari or the Dravidian language support soon.

I also vote for this feature. I feel like Serif is shooting themselves in the foot by leaving out the potential market share with the ability. For me, I am learning Hindi Devanagari and would make helping note cards and etc to help reinforce my skills. Using the glyph browser is the band-aid solution and not a proper work-around.

CPU: Core i5 750 @ 2.67 GHz RAM: 16 GB GPU: Radeon RX 460 C-Drive: Samsung 860 SSD EVO 1 TB So..for you, there is absolutely no lag during the stress test? Even when you vigorously move your mouse hand and do crazy circle motions? Both the curves interactivity and refresh/redraw is butterly smooth for you?

I don't have any programs running in the background, other than my Creative Cloud software, which runs at startup for access to my files and Adobe fonts etc. I loaded my PC without any programs starting in the background and it's the same...as in anytime I perform layers test, the "lag" shows up. I am not too stressed/bothered by this, since I have the remaining year of 2021 for my Creative Cloud Photography Plan. I started this topic in 2019. With Photo's Open CL, it helped a lot, but the "lag" shows up immediate with increased in layers. I think Gabe and others have said might be correct. Photo's layer is live and my 2009-era dinosaur is simply too much. One thing that still puzzles me why the performance disparity when the layers are collapse versus uncollapsed as I have demonstrated. Even on my dinosaur system, both should experience lag due layers. Grouping layers shouldn't affect, but I have shown in my video the opposite effect. Uncollapsed grouped layers shows performance within tolerance.

For public purposes, I made this video. Please, if anyone wants to chime in and report back if you receive similar experiences with the performance results between collapsed and uncollapsed group folders. I think this is worth investigating for the improvement of Photo. Despite my original title, the "lag" doesn't need to be a huge file with multi layers. I've demonstrated in my video that the "lag" occurs on a JPG file with 2046x2046.

Yes, I am reuploading as I reply to this post. I dragged-and-dropped and entered my name and email. The filename is "TAN-09-06-01.psd" and it is 781 MB. If this doesn't work, I'll simply upload to my CC Assets Folder and provide a link for you to download to check/replicate/verify. Is there a way for us to message one another directly at the forums? If not I would email you the link. I feel like this could be "something" worth investigating for the the future develop performance of Affinity Photo. If anyone wants to test and see if the collapsing and un-collapsing of GROUPED LAYER has any significant affect on Photo redraw-on-screen performance. I think the test is fairly simple. On top of your Background document, preferably with images. Create a Curves adjustment layer. On this, vigorously move your mouse-hand up and down on the curve and you should see buttery-smooth redraw on the screen AND the buttery smooth of the curve reacting/responsive to your vigorous hand movements. Here is the Test. Next, make several copies of the Curve Adjustment Layer...I am talking about 10 or 20 copies via CTRL + J. Click the newest duplicate and you should expect "lag" in both the curve responsive behavior AND the redraw/refresh on screen. Next: Group ALL the duplicate you made, and LEAVE the topmost curves adjust duplicate. You should now have: Background, [GROUPED Duplicate Curves], and the single curves adjustment as layer structure. Next to the Grouped layers, you should see a triable to collapse and un-collapse. Test the vigorous hand motion on both cases and you should see something of an "Aha!" moment in regards of performance. My results indicate that when the group layers are UN-COLLOPSED (you can't see the layers inside the group), the performance in both curves responsive behavior to the move movement AND the redraw is within acceptability tolerance. Please let me know if others are can chime in and see if they are getting similar results.

Hi Gabe, Thank you for looking into this matter. I am uploading the 781 MB file as I reply to your post. See if you get similar "lag" as I have arbitrarily testing on my 2009-era PC from Hewlett-Packard. To Test: 1. Add a curves adjust layer above the "Merged Layer (Do not Delete)". With your mouse hand, vigorously move in up-down motions to stress/test our the curve graph responsive behavior AND to see the animation refresh update on the screen. If you're doing this correctly, you see see "lag" as I have demonstrated. 2. Group ALL the layers except the curves adjustment from (1) and the background layer. 3. Repeat the vigorous mouse movents. 4. Repeat, but un-collapse the grouped. If done right, you should see acceptable performance.

Do you see a slight "Aha!" moment, when I press the triangle to un-collapse the grouped layers? The performance is acceptable and no longer "lags" as per my statement. I don't see this "lag" when I perform the same test on my Photoshop CC 2019. I purposefully remained at CC 2019 due to performance issues in 2021. Again...another story for another time. What I want anyone to pay attention is the curve animation AND the screen redraw. People can't see, but what I am doing is vigorously moving my mouse-hand up and down. You can see the smooth results when dealing without any layers. What I would like to request for future IMPROVEMENT is to experience the SAME performance without having to group the many layers AND not having to un-collapse the grouped layers, if that make sense.

https://youtu.be/KtHUWkEASh0 I don't think my mic recorded my voice explaining. This has been bugging me and mainly preventing me from cancelling my Adobe CC. This and amongst other oddities, which is for another time.

Hi Gabe, Circling back to this topic. I think I may have spotted another oddity. I am now testing out the 30-day trial of the publicly released 1.10. If you don't mind following my steps, I wanted to know if you also spot this newfound "interesting" oddity. 1. Open a document, say a big file. Flatten it. Add an adjustment curves layer. Make random arbitrary adjustments. Duplicate this adjustment layer like 20 times. You should now have 22 layers: background, the test curves adjustment layer, and the 20 copies of this test layer via CTRL + J. 2. You should expect a severe lag! 3. Here is something I found: this is interesting. Group all the test curves adjustments layers, while leaving the sole one on top. Your layers should like this: background, grouped test curves layers, and finally that single test curves layer at the top. 4. Double click on that single top curves and you should see negligible lag, as if super smooth and responsive screen refresh. Why is this? Is this considered an oddity in a sense that even if I don't group all those test curves layers, I should get the same negligible lag and smooth results.

[REDACTED] I'll simply wait until the final version of 1.10.X and test the performance oddities myself.

I was hoping a feature to be implemented in version 1.9 release of Affinity Publisher (AP). It's not. Regardless, it's one of my favorite software purchases in 2020. I do hope the ability to format output names in AP would be added in version 2 of Affinity Publisher. I can hope. 🙂 Thank you.

Hi Gabe, I wanted to update with the recent final version of 1.9.X Affinity Photo (AP) that I'm trialing again. I have been a super happy customer of Publisher, since I purchased it aforementioned months ago. The lag with curves adjustments in my OP "seems to be fixed" with the support of OpenCL in AP 1.9 released February 5, 2021! With a single background pixel layer, the curves adjustment with Open CL supported on 1.9 is instantaneous in BOTH the curve draws (placing points for manipulation) and the image feedback (screen refresh). My computer and the software installed are the same when I make my OP. Wonderful congratulations to the Serif Team and the beta/QA testers for the release of AP 1.9. BUT...yes, there is a BUT. As soon as I duplicate the background pixel layer several times, e.g. 10 or 20 for the purpose of testing and pushing the limits, I experience that same slow down (lag) I reported in my OP.

Apologies if I overlooked the lists of approved hardware for OpenCL. If not already, will you please provide some sort of a list or prelist with preliminary testing of GPUs? I currently have AMD Radeon RX 460 (current up-to-date WHQL certified) and it suits my needs and I don't plan to upgrading to another GPU. Additionally, I'm currently a Publisher user and like the software. I have been curious about the hardware acceleration in a forthcoming version of Photo.