Jump to content
You must now use your email address to sign in [click for more info] ×

Affinity Designer Customer Beta RC3 (1.1.2.23834)


Recommended Posts

  • Staff

Purpose: Improvements, Features, Fixes

Status: Release Candidate

Requirements: Purchased Affinity Designer

Mac App Store: Not submitted

Download: https://s3.amazonaws...stomer Beta.dmg

 

This is our intended final release candidate. We intend to update the currently available Mac App Store product in the very near future. It would be particularly helpful if any interested testers could take a look at the Spanish translations to ensure that they are acceptable as these have come back very recently and we have not yet had them validated. As before, we would appreciate it greatly if you are able to spend some time looking at this release candidate version and thoroughly testing it, letting us know any issues that you are having with it so we can prioritise our time to tend to as much as possible.

 

To use this beta, simply download the file from the link given above and double-click on the file to open the installer. Follow the instructions to install the beta version. The beta sits alongside the Mac App Store version and will not interfere with it.

 

Documents made in this version will not be openable in older versions of Affinity Designer. This change was necessary in order to ensure a consistent baseline for our file format for the Affinity Photo Beta. When we update the Mac App Store version it will upgrade to this new archive version number too so will not be an issue in the future.
 
Improvements, Features, Fixes
 

- Fix for slow startup experienced by users with many fonts

- Fix for 'baking' corners causing the start/end node of closed curves to show slightly strangely in the node tool

- Fix for selective colour adjustment not correctly saving itself with the document

- Fix for problems experienced with WebDav shared folders causing inability to save over existing files

- Fix for many clipped translated strings

- Fix for some PSD export issues - crashes caused with masked areas

- Improved EPS loader so that it tries to identify CMYK/RGB documents

- Show the modified document before asking if the user would like to save its changes

- Fix for some incorrect states shown in the Select Tool's context toolbar

- Fix for EPS export of CMYK JPEGs used in the document (they were becoming inverted)

- Failing to read DPI information from a PNG should default to 72 DPI

- Fix for Black & White adjustment not allowing slider changes

- Attempted fix for disappearing tab bar when multiple documents are opened

- Added a check next to the current view in the Views->View menu

- Fix for some issues seen in Path Text

 

Link to comment
Share on other sites

Great Matt, the corner bakery now works perfectly ...  ;)

 

Unfortunately the tab bar issue is still there on OS X Lion, but the behavior has changed a little in the right direction. Whenever you close the app, launch it again and open two documents at once, the tab bar now shows up correctly. But whenever you close the documents (not the app) and reopen them again, the tab bar remains invisible ...  :(

 

But this is a minor issue, as there are many good workarounds ...  :)

 

EDIT Deleted attachment due to upload limits.

Link to comment
Share on other sites

My beta expired today so I upgrade to this one.  Within a few minutes of use the app locked up.  I was having lots of troubles selecting various items embedded within layers which was never a problem before.  Sorry for the vagueness of this bug report but that's all I've got at the moment.

Link to comment
Share on other sites

  • Staff

Great Matt, the corner bakery now works perfectly ...  ;)

 

Unfortunately the tab bar issue is still there on OS X Lion, but the behavior has changed a little in the right direction. Whenever you close the app, launch it again and open two documents at once, the tab bar now shows up correctly. But whenever you close the documents (not the app) and reopen them again, the tab bar remains invisible ...  :(

 

But this is a minor issue, as there are many good workarounds ...  :)

 

Hi A_B_C, I was able to reproduce your bug with your recipe I've put in a fix for that case and it would probably go into the next update. Thanks! :)

Link to comment
Share on other sites

  • Staff

My beta expired today so I upgrade to this one.  Within a few minutes of use the app locked up.  I was having lots of troubles selecting various items embedded within layers which was never a problem before.  Sorry for the vagueness of this bug report but that's all I've got at the moment.

 

When you say locked up, do you get the spinning beach ball? or a crash report? Do you remember what your last few actions were? or is it on the application startup?

Link to comment
Share on other sites

When creating stokes, it looks like it defaults to black stroke color even though a different color was used previously and is shown in the selection window.  Please see attached.  Wouldn't the desired objective be for it to default to the last stroke color that was used?

 

 

post-4966-0-39139500-1426637093_thumb.png

Link to comment
Share on other sites

Please see the attached file to see additional problems I'm having with divide/add operations.  I am assuming that there is a limit to the number of nodes that are allowed to be divided and added to prevent memory issues?  Is this a correct statement?  My workaround is to perform divide and add operation on one letter at a time but this is a slow process.

Operation Errors.afdesign

Link to comment
Share on other sites

  • Staff

When creating stokes, it looks like it defaults to black stroke color even though a different color was used previously and is shown in the selection window.  Please see attached.  Wouldn't the desired objective be for it to default to the last stroke color that was used?

 

Hi Signguy,

 

It should be defaulting to the colour shown in the line colour section of the context toolbar... Have you got multiple objects in your selection? Perhaps there's an issue with that logic because I've just tried it with a single object and it works as expected...

 

Thanks,

Matt

Link to comment
Share on other sites

  • Staff

Please see the attached file to see additional problems I'm having with divide/add operations.  I am assuming that there is a limit to the number of nodes that are allowed to be divided and added to prevent memory issues?  Is this a correct statement?  My workaround is to perform divide and add operation on one letter at a time but this is a slow process.

 

Hi Signguy,

 

There's no limits to any operation - it's just that some operations (divide in particular) are exponential in order with respect to the number of inputs, so it's probably just rapidly slowing down past a certain point. I intend to look at boolean geometry as a priority as soon as this update has gone live. I can only offer my apologies in the meantime - I will get this sorted properly, but I cannot risk rushing it because it may end up much, much worse! :S

 

Thanks,

Matt

Link to comment
Share on other sites

Dear Matt,

I tried EPS testing today. I exportet and importet them. Also I used some older EPS (Illustrator) files for testing. And what should I say? They look just as they should - great work done, your solution seems to work perfectly for my purposes. Thank you so much. I don't know if lastly all will be ok, but all files I tried were perfectly usable for my purposes.

 

Keep up the good work and best wishes :D

Markus

iMac (Retina 5K, 27-inch, 2017), i7 4.2, Radeon 580 Pro 8 GB, 40 GB DDR4-RAM, 1 TB Flash, macOS 10.14.6

Link to comment
Share on other sites

I found a little nasty bug with raster brushes that I hope you guys can replicate easily...

 

1) I work mostly on a Cintiq and Mac Mini so I have not experienced this issue until playing around with a new Retina Macbook Pro (in default resolution 1280x800@2x). 

 

2) In the beta and app store version I discovered that when you hover a raster brush that it pixelates an existing line on the edges of both raster and vector lines. When you make a stroke or do something else, the existing lines go back to being sharp.
 

3) It seems to be doing this in even in native pixels 2560x1600 (using RDM), but it's very faint. Perhaps the other displays don't make this effect noticeable, or perhaps it is an issue unique to HiDPI displays.

Link to comment
Share on other sites

  • Staff

Hi specworkfan,

 

This isn't a bug and there's nothing to fix - it's actually the only reason that your retina device is able to offer performance similar to that of a non-retina device... :)  We deliberately do a screen draw at non-retina resolution and then do a screen draw at retina resolution immediately afterwards. What you're noticing is the non-retina draw on your screen in the areas where you're moving.... If you pause for even a moment it will become retina again. It took a lot of effort to make this work and is possibly the main reason that Affinity is a much better experience than other apps on retina screens, so it's really a necessary evil - after all, you can't do 4 times the amount of processing (for a retina draw) in the same amount of time so you'd have to wait 4 times longer to see anything - and that's what you do in other apps, whereas we respond and draw immediately, then do it properly straight afterwards to improve the user experience and stop you waiting for things to finish. If Intel could produce a chip with more cores then we could probably just disable this approach, but as it stands the limitation is on how much processing power is available, so we get around it in this way.

 

Thanks,

Matt

Link to comment
Share on other sites

In the first release, we could select an element or a layer and drag and drop it on the icon "Add Layer" to copy.

I prefered this method instead copy/paste because with copy/paste, copy is almost never where you want (If I copy Layer 1 and paste Layer 1 (which becomes Layer 2), Layer 2 is inside Layer 1)

 

Icon of the app is pixelated when you are using CMD+tab.

Link to comment
Share on other sites

Hi Matt,

 

I am aware that this is somewhat off-topic, since it is not a a bug ... but would it be complicated to enable the stroke alignment options for non-closed paths as well? Might simplify UI design, now that half-pixel snapping has gone ... personally I would like to have this, and if it’s done with a few lines of code, why not enable it for the update ... or am I missing something? Is that option already there? ...  :unsure:

 

But thanks for all your hard work ...  :D

Alex

 

EDIT Deleted attachment due to upload limits.

Link to comment
Share on other sites

  • Staff

Hi Alex,

 

It's all in and working, but it causes a visual artefact in some circumstances - I noticed that I get exactly the same artefact in iDraw in exactly the same circumstances as it does allow you to do what you're asking... I'm tempted to enable it, but it would need testing rather than being part of the update and inadvertently causing nightmares for people...

 

Maybe I can reconsider on it - watch out for it in a future beta! ;)

Matt

Link to comment
Share on other sites

My apologies for being an impatient ninny (as I haven't been using the Beta versions since I started using the MAS version), but when do you think all these cool new features and bug fixes will be released to the App Store version? Are we talking days or weeks?

 

Can't wait to use all the cool stuff......(and thanks for all your hard work)

 

George

eejits: a curious collection o' creatures - www.eejits-online.co.uk 

SUPPORT eejits on PATREON. Exclusive Content & Rewards available! www.patreon.com/eejits

Get some awesome unique eejits merchandise at https://www.eejits-online.co.uk/shop

Link to comment
Share on other sites

  • Staff

My apologies for being an impatient ninny (as I haven't been using the Beta versions since I started using the MAS version), but when do you think all these cool new features and bug fixes will be released to the App Store version? Are we talking days or weeks?

 

Can't wait to use all the cool stuff......(and thanks for all your hard work)

 

George

 

A lot sooner than you think! :p

Link to comment
Share on other sites

It's still a bug though, because the same behavior exists when you switch the retina display to native resolution (which has the same pixel density as a non-retina) monitor. Perhaps Affinity should check for retina and then the actual resolution setting to see if it is a HiDPI one or not?

 

Also, wouldn't making brushes @1/2x solve this issue? I can understand now how high res brushes can easily make things lag, but it would be nice to not have this by option. It's not a problem for me, I work on an external monitor, but it is definitely not a good experience for raster on retina. I would rather have the brushes effectively only make a @1/2 pass and zoom in, than to have this effect.

 

Finally, have you tried this on a 12 core Mac Pro without this setting? If it works with only a retina pass, it probably should be an option, although it's going to affect very few users now with Mac Pros and HiDPI external displays. I think apple will come out with their own retina cintiq this year as the iPad pro which probably will double as an external monitor.

 

 

Hi specworkfan,

 

This isn't a bug and there's nothing to fix - it's actually the only reason that your retina device is able to offer performance similar to that of a non-retina device... :)  We deliberately do a screen draw at non-retina resolution and then do a screen draw at retina resolution immediately afterwards. What you're noticing is the non-retina draw on your screen in the areas where you're moving.... If you pause for even a moment it will become retina again. It took a lot of effort to make this work and is possibly the main reason that Affinity is a much better experience than other apps on retina screens, so it's really a necessary evil - after all, you can't do 4 times the amount of processing (for a retina draw) in the same amount of time so you'd have to wait 4 times longer to see anything - and that's what you do in other apps, whereas we respond and draw immediately, then do it properly straight afterwards to improve the user experience and stop you waiting for things to finish. If Intel could produce a chip with more cores then we could probably just disable this approach, but as it stands the limitation is on how much processing power is available, so we get around it in this way.

 

Thanks,

Matt

Link to comment
Share on other sites

Yep, they are really terrible, but surprising a top rated OSX app gets treated even worse than the lowly iOS developers who churn out spun garbarge hoping to snare an elderly user into parting with 99 cents. You'd think they would do anything they could to encourage growth of the app store. As it stands now, the vast majority of apps are either poor quality, or more outdated than the need to be.

 

We're talking weeks. We're in the process of submitting it, and after that it depends on Apple. It usually takes them a fortnight to approve it. Longer if they find some problem.

Link to comment
Share on other sites

I don’t know, if I should add these minimal finds on OS X Lion 10.7.5 (seems a bit nit-picking), but nevertheless, here they are: Close the app, open it again and bring up the media browser. You will find that the slider at the bottom gets visible only after you touch it ...

 

And there seems to be an icon missing left to the slider. I was just taken aback by the additional *hidden* features of the browser panel ... very handy indeed ... but unfortunately invisible ...  ;)

 

Some other minimal things in the German localisation ... but yes, I am a bit embarrassed to note these at all ...  ;)

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.