rubs

Me neither Just a wild idea. It would be very nice to optionally separate these units if desired. That would be handy for UI design, but probably not so useful for graphic work. I believe allowing professional users to change advanced settings like this would resolve hundreds of discussions at once. Oh well...

Just tried placing a random PNG on a new document and AD crashed immediately. (No bug report window appeared, BTW). My session had one unsaved document and was opened for some hours now, maybe this helps on reproducing the issue.

Unfortunately I don't have a path to faithfully reproduce this bug. Closing and opening AD solved it. I'll keep an eye on it, though. Yes, but if I do that I'll see all text in pixels, which may be not what I want. Maybe separating distance units from text units would be a better idea...

Just think about it, a high number of decimal places is for enhancing precision in pixel-perfect designs. Using the mouse wheel on the tab size field is for increasing efficiency. I don't see a relation between the two. Since working with tabs in AD is already very difficult, removing the ability to quickly change tab spacing with the mouse wheel further impairs a very incomplete implementation. The obvious way of doing it, which is dragging the tab stops on screen like everybody else, was never implemented. In any case, what you guys really should have done was to expose increment values as an user option, not to hardcode it.

A known workaround with AD is to scale your object up, say 10 or 20 times, expand strokes, then scale it back. The issue with expand stroke is not very noticeable with large objects. Yet the feature does need fixing, of course.

Yes, it may happen a couple of times in a multiple-hour work session, when we frequently toggle pixel alignment and snapping and change zoom levels. I remember this issue was addressed some years ago and it got better, but was never solved completely.

Yes, Serif's feedback about software development is quite sparse. They must have some strong internal policy about this. I'm sure making things more transparent would benefit everyone.

I recently noticed that, in some cases, clicking the Paragraph Leading value changes its value to something completely unexpected. In the example below, value changed from 9.2pt to 1.314 (without units). By the way, yt would be nice if AD retained the unit entered in the Character and Paragraph fields. E.g. "20 px" gets converted to "18.8 pt", which is not very informative. But I believe this would be best suited to the wish list.

In version 1.7, using the mouse wheel in certain fields does not increment with integer values anymore, at least when using 6-digit precision. Here's an example: I hope that's clear for you to understand.

That's great, Mark. Thanks!

I feel it's better than v. 1.6 and that may be true for a single file, but unfortunately this is not my experience with the beta so far. I felt it was slower than when I started the session so I closed and reopened AD. It's a lot faster now. Perhaps it would be useful to know that the memory footprint decreased from 1.7 GB in the previous session to 580 MB now, with the same two files opened. In the previous session I had opened a series of other files (mainly .ai and .eps) and copied and pasted the contents in another file. Maybe AD still has problems with garbage collection.

Makes sense. I don't use Photo, so maybe that's why I didn't notice any dramatic improvements. Thanks for the info!

Comparing photo editors and discussing about assembly are very interesting subjects, but I suggest moving these posts to another topic (if possible) because they deviate so much from the original question. Speaking of which, would you please let us know a bit more on the latest performance improvements? Thanks.

Some feedback on this matter. I'm working on a new artwork this afternoon. My document is pretty small (80 kB) with just two artboards and some logos. The beta seems faster than 1.6 when zooming, except that, if vibrance adjustment is applied, image tiling is still quite visible. But I saw no performance degradation yet, which is a good thing.

Specifically, where these performance improvements will be best noticed? There are several areas where AD need performance improvements. From the top of my mind: zooming, rendering (screen tiles / big pixels are visible), selecting and deleting objects, searching assets, startup, typing text, etc.

Looks like a much needed fix for the Windows version! @Mark Ingram, I've not used v. 1.7 much yet -- could you please elaborate on this a little bit? Have you improved hardware acceleration? Other users may have some reports on this, I'd love to hear about it. Thanks!

This is getting old... I secretly hoped they would fix constraints for 1.7.

I wouldn't mind embedded images being the only option if AD compressed them, but since this doesn't seem to be the case, I wonder if this means we are stuck with those giant file sizes forever.

Just a follow-up. Actually it took about 30 minutes. The download speed varied wildly during the download.

Maybe you'd like to know that while Designer 1.6.5 (from store.serif.com) loads in less than a minute, the beta download is very slow. Chrome says it won't be ready before a couple of hours (!)

Er... Didn't try the beta yet, but AFAIK version 1.6 does. Does this mean that 1.7 will be slower than 1.6? Please explain, thanks.

Yes, that or an additional checkbox in Preferences > Tools panel. Also, selecting multiline text lines (artistic or paragraph) may be also confusing, since the selection is based on the bounding box that surrounds the text block... Another new check box for that would be nice

Any conversion from PNG to BMP and vice-versa should be pixel-perfect since both formats are lossless. Bad results are often due to use of JPEG images or scaling. It would be best for you to upload both images here so we can see what's going on. Cheers!

Hokusai, Affinity Designer is now my main UX design tool, and I use it very heavily on a daily basis since the first Windows beta. I think it has one of the best UIs around and certainly the best workflow for my tasks. As a professional UX tester, I tend to take bugs quite seriously. I keep a record of all AD issues I know of, and I also use this forum mainly to report and discuss them, helping the team wherever possible. As for the platforms, most problems I know of seem to be common to PCs and Macs. All things about artboards, symbols, grouping, compounds, constraints, export persona, adjustments, etc. seem to reside in the main code AFAIK. But I also know there are performance problems and some other issues that are specific to the Windows version. Anyway, AD is still my main and tool and will continue to be, hopefully for a long time. I hope it evolves in a positive way. This obviously includes keeping the platform as stable and bug-free as possible.

But unfortunately Affinity Designer has hundreds of bugs. They range from simple issues to fully problematic areas (like constraints), plus serious memory and performance issues on the PC. I believe the team is fully aware of those issues and they will address them sometime, if not already.