User_783649

I have been evaluating the compile latency of AMD drivers, using the code posted by the developers at github for a few months now (since i noticed the issue myself).
https://github.com/MarkIngramUK/ocl-compile-benchmark
My experimentation in Windows 11, starting from driver Adrenalin 21.10.2 all the way up the most recent Pro 22Q2 shows very reasonable latency with the latest (22Q2) being around 62-63ms on an RX6900. The best result on Windows was with the default Win11 driver (no AMD driver installed) with a latency slightly above 53ms, while with a small modification (of time measurement code) the same code can run in Linux. I tested it with the open source driver (in linux-kernel 5.17-5.18) the latency I measured was around 22ms. So, no matter how hard i tried to reproduce the issue (out of my own academic curiosity); i couldn't get any latency in the order of magnitude mentioned (of around 1400ms) in the github post (for the Radeon 5000 series).
Sadly it also seems that all recent Affinity releases have this restriction, so there is now way to enable HW acceleration in the application and test it, if they don't remove this restriction in a future release. We can only hope that they address this issue at least in their next major release (v.2). And i personally don't see a reason for it any longer, although i understand that there might have been an issue affecting several users at a given point in time using a specific system configuration (OS, driver, etc). Even if for specific configurations this might still be the case, i believe they should make it at least possible to enable the hardware acceleration (even if we need to acknowledge the risk and modify some configuration file) in any OpenCL capable device, so that we can also measure the performance from the benchmark as well as in real test cases in the application and provide feedback back to the developers.

Including updates for several years now, at no extra charge. Some people may say say the updates are adding "missing" features, and that is true to some extent. But they are still updates included in the initial price.

You disagree that every company is different? You have no clue what spending is like internally, what they prioritize in terms of staffing from developers, techs, IT, CSR's, sales, etc. Every company is the same in that they all have similar roles to fill, but how the do it and what they prioritize will be very different. 
Not sure what your point is regarding Adobe. Adobe makes the 3 big apps that Serif has offered alternatives too: Indesign, Illustrator and Photoshop. Adobe decided it was not worth developing for Linux and I am assuming that it is because it does not predict the returns to be worth the money that would be put in to developing and supporting Adobe CC on Linux. Serif cannot avoid being compared to Adobe as again, they are making direct competing software of Adobe's big 3 apps. Serif is going after a different market than Adobe. Adobe is not made for the home user who wants some reasonable design tools and options at an affordable price. Adobe is the standard in many industries and made for the pro user, pro user as in people who make their living with the Adobe software. Serif is no slouch, but they are not Adobe and not in a place for most to give up a standard and all the great things that come with Adobe CC. If I was working on my own, just doing my own poster printing for people out of my house I would go with Serif for sure. In the print/design world where standards matter and equipment is made to work with Adobe, and you need accurate file reproduction as well as collaboration, Adobe is it. 
I am sure there are lots of things missing or people would like changed. I don't use the Affinity apps for work though I bought all 3 to check them out and see how they compare and if it would be something we could ever switch to at work. Serif has done some amazing work and produced some high quality software for most people at a very affordable price, I find it hard to complain about lack of features considering the price point.
Serif has made it clear they are not developing or planning to develop for Linux, the market is small and I am assuming Serif does not see great gains for the effort it will take to support a Linux option. And again, I don't think anyone is hating Linux, there is no passion for not developing for Linux. What there is is reason, and I would say the passion is on the other hand in the Linux community who just can't accept that developing for them would not be profitable. 
 
 
 

In context of changing from U.S. Web Coated v2 to Coated Fogra 27 (both allowing pretty high total ink coverage values) this is a valid question, but assignment cannot [always] be used if profiles differ significantly from each other. To avoid simplistic instructions, let's see what happens when reassign is used when changing from Fogra 27 to newsprint stock, e.g. ISOnewspaper26v4, which allows max ink coverage of about 240% (many newspaper profiles might have max TIC below 200%):

reassignment.mp4 So simply just reassigning would in this case produce a print file that has over 100% too much ink and would be rejected by the printer (and if not, produce catastrophically dark mid and shadow tones).
I used a newspaper profile just to accentuate the importance of making right selections when changing profiles, but the choice becomes relevant already when changing from standard coated profiles to e.g. ISO Coated v2 300% (ECI) -- a very common profile used for coated stock in European press, which allows about 45% less ink than e.g. Coated Fogra 27. You cannot [necessarily] just reassign the profile in situations like this, but [might] have to convert [-- whether this is needed depends much on how much control is needed and how massive immediate conversions need to be done and how much can be left for the export time conversion]. And then change "inadvertently" converted K100 back from rich black to K100. You can often facilitate that with styles, or Find / Replace formatting, but just supporting [Black] in the style of InDesign would make such operations unnecessary.

So, why not pick Assign instead?

Nice result @Alex M

Another way of achieving similar effect would be using a real water ripples photo as a map for a live displacement filter.
It gives us more control and realism over how we want our image look like in the end.
We can apply various water ripple images and try them with live displacement to find the best look.
We can control how much water overlays, shadows and highlighs you want over your house reflection.
I just played a bit with your house image and here's my modest attempt.

At the moment what has sort of worked is having light blue colour instead of the orange and at the moment i have only tried 180px x 180px

Whatever you throw at Instagram became converted to JPEG on their servers with aggressive compression settings being applied. Unfortunately, you can't avoid that.
If Instagram used 100% or at least 80%-90% quality for avatars it would be way less prominent. But they are too greedy and probably use something like 30%-50%.
Less storage space, less traffic, lower datacenter bills.
JPEG as a format doesn't like sharp object edges with high local color contrast (your image has them).
These areas will always have artifacts and quality will degrade severely here as compression ratio goes down from 100%.
The best you can do is to try changing colors and see if it improves the quality.

The customers are just not there. Not anywhere near enough. Companies that have tried have been bitten. Corel, WordPerfect, Borland, ...
Linux's place is on the server. On the desktop it is insignificant.

Maybe an explanation: once you stretch layer dpi above 200%, AA calculation gets wrong. As the pixels in the bitmap layer might get too far away from the edge of the canvas pixels, Affinity forgets to include them.
Looking at the file with Designer helps to spot the issue, when you activate vector and pixel view in parallel.
I filled the 10x10px rectangle with a checkered board, this time you see all channels normally.
A levels adjustment was used to boost all nonzero alpha to 100%.
You can see that the canvas pixel directly right to the vector/pixel slider is fully transparent. This is a bug. It should be partiality  transparent about 10%, according to the small share intersecting with the bitmap layer.


rect res aa issue.afdesign

No AA above 20px

Strong AA/smoothing below 20px

Hi, 
i tried to understand how anti aliasing works on iPad (view mode is fixed to bilinear).
I start with a rectangle of 10px width, then stretch it to about 20px, and rotate it.
what really surprises me it how resampling / anti aliasing works on the edges.
as long you only rotate, you get a nice expected AA of about 2px width around the edge if you stretch to 20px (factor 2), but play a bit around the exact number, it becomes really strange. One side gets smoothed over 4-6px, but only when below 20px. Above 20px, AA almost stops working. The other edge has its own impact. To summarize, i could not find a clear explanation why and when the edge AA kicks in, and at what scale (1px, larger that 1px).
The video shows the alpha channel only (via channels panel).
 

IMG_3377.MOV

I prefer Affinity because it is faster and more intuitive. I find Adobe apps clunky, overpriced, and painful to use by comparison. In this case, I would have distorted the vectors in another app but a) I didn’t anticipate this graphic being requested for another use where vectors would be required. It was a simple landing page graphic. And b) going into vectorstyler, which I do use occasionally, is an awkward workflow that adds time to the task. Vectorstyler and Inkscape also have clunky interfaces by comparison. Affinity suits all of my needs 98% of the time, but that missing 2% is irritating because it shouldn’t be that difficult to add the missing key features. I do use alternative apps for other features too like auto trace. Still, it would be better to have these at the ready within the app. I handle incredibly high volume for multiple agencies. They value my efficiency, part of which is made possible by Affinity’s intuitive interface, which is reminiscent of Fireworks, a tool Adobe acquired and then killed, not realizing its efficiency advantages.

None of this has convinced me that my primary OS should be Linux and, anecdotally, that goes for most of my friends.
I have a distro running ATM, Mint as it happens, which I use to tinker around with for "fun".
However all my "real work" is still done on Windows. The software just works and I don't need to worry about what display protocol I'm using or needing to tweak Wine or any other esoteric settings. It also means that I can get support from the developers that I've paid good money to. Even if something works under Wine most Devs are of the opinion that you're on your own when something goes wrong.
People I know who run small businesses are generally not tech-minded. They're very good designers or architects or business consultants but just need an OS that works out of the box with the minimum of setup. They don't even want to decide on a distro as it's too much of a hard choice, especially as my Linux evangelist friends all recommend something different.
I also don't need to worry about a "particular set of developers" screwing things up for me.
Both OSs have their faults and their benefits. For work, at the moment, Windows is the lesser of two evils.😉

This in a nutshell is THE problem for Linux. If I want to install a graphics app I might have to Google for Wayland bugs. That is not my problem. If Wayland becomes the standard for Linux then this app will not work.

i did a quick search and you can't change polling rate on this model.
it seems to be 125hz

It seems that my affinity publisher suffers from low refresh rate.
To best describe it, it really looks like i was playing a game and Vsync was off, it's most obvious when i move a picture around.
this picture, even though it's about a game, looks very similar to what i see on my screen in publisher:

I tried messing around with the performance settings, but didn't manage to find a solution.
i also turned on vsync in my nvidia control panel but still no solution.
can you please help me?

What stops you guys from toggling an option in User Interface preferences? It will make all icons turn to monochrome.

Like I mentioned in my previous comment, I get that at a certain point you want to actually see the individual pixels, and you are correct that using bilinear at that point would not be appropriate. But the zoom levels between 100% and that point (excluding exact increments of 100) look really bad in AP and do not represent what the image actually looks like.
Here's another comparison that should illustrate the problem. The left image is a screenshot from GIMP of a section from the original image, with the canvas zoomed to 125%. The middle is a screenshot of the same section of the original image displayed in AP, again with the canvas zoomed to 125%. For reference, the right image is the same section of the original image, unscaled.

To me at least, it's pretty clear that GIMP is doing a much better job at representing the original image. And when you zoom in close enough with GIMP, you can see the discrete pixels fine without any blurring. This is the behavior that I've seen in every other photo manipulation/painting application that I've used. I'm sure they all have different implementations, some better than others, but none of them distort the image this much. The stair-stepping and varying "pixel" sizes seen in AP here is not representative of the original image, it's an artefact of using the NN algorithm in these scenarios.

The options for Performance / View Quality have room for improvement:

1) Trilinear Filtering should work on modern GPUs easily.

2) Filtering should be optimized for smaller / larger zooms, especially uneven zooming (like 70%) looks pixelated.
3) Different quality options for more / less than 100% would be great. Some people might appreciate no filtering above 100%, others not.
Thanks and keep up the good work!

Hi @Rogurt,
I can confirm this issue relates to the inability to see objects that extend over to the bleed area on artboards, this is currently logged with the developers for resolution.

Ohh, don't bring up the old stuff ... Only gets me into trouble. I always get a shitstorm for reposting
But frankly spoken I had the impression that 5 years gone by justifies to put up a little reminder .... and we are not asking for functions to construct frequency separated intersections between penguins and octagons.
<sarcasm on>
And I guess it's still a huge surprise for serif that there are people out in the world that try to productively use their tools
<sarcasm off>

But as I said - let's hope for AP 2.0

@DarkClown I fully agree with you — it would be nice to have a kind of output sharpening parameters section somewhere in export options. Having to go through multiple rounds of exports seems very inefficient.
Btw, I found your thread from 2017 with the same question: 
Unfortunately, it seems like nothing has changed in this regard.
Hopefully we'll see some improvements in next versions.

OK, thank you.
It's not what I would call a proper "workflow" .... more something like a "workaround" 🙂 ... Let's wait for AP 2.0