Alex W

Clear history would still be really nice though, as it would allow clearing the history from memory whilst working on a doc to help performance.

I appreciate you trying to help but whilst it sounds good in theory I can't change the relationship of the original content as this will make that blurry to start with.
I'm already using a manual process to deal wit this and the point of the comment was really that when you have move by whole pixels and force pixel alignment turned on, it would be handy/intuitive if transforms and alignment respected the current pixel alignment of layers and images too, to avoid having to manually correct things.
Here is an example
Before mirroring a group

After mirroring a group with original still behind. You can see the extents of the group and it's centre point are the same, but because of the fractional pixel size the actual pixels get offset by a fraction of a pixel and thus become burred.

So far the only way I can find to resolve this is to rasterise and trim, which trims the rasterised layer to a whole pixel size and mirroring then works fine. But this is obviously destructive and doesn't work for what I need to do. I currently have to turn off pixel alignment and manually drag the mirrored version horizontally until the images look the same.
It's a particular issue for me here, but more generally people may not realise that mirroring an image/layer/group which has a fractional pixel size could subtly change the way it looks... this may not matter in many cases but it could for some. Given this I actually think it should be changed so that in general mirroring or aligning doesn't change the relationship of pixel data to the pixel grid, by default, and you have to actively change the behaviour if unwanted.

I appreciate you trying to help but whilst it sounds good in theory I can't change the relationship of the original content as this will make that blurry to start with.
I'm already using a manual process to deal wit this and the point of the comment was really that when you have move by whole pixels and force pixel alignment turned on, it would be handy/intuitive if transforms and alignment respected the current pixel alignment of layers and images too, to avoid having to manually correct things.
Here is an example
Before mirroring a group

After mirroring a group with original still behind. You can see the extents of the group and it's centre point are the same, but because of the fractional pixel size the actual pixels get offset by a fraction of a pixel and thus become burred.

So far the only way I can find to resolve this is to rasterise and trim, which trims the rasterised layer to a whole pixel size and mirroring then works fine. But this is obviously destructive and doesn't work for what I need to do. I currently have to turn off pixel alignment and manually drag the mirrored version horizontally until the images look the same.
It's a particular issue for me here, but more generally people may not realise that mirroring an image/layer/group which has a fractional pixel size could subtly change the way it looks... this may not matter in many cases but it could for some. Given this I actually think it should be changed so that in general mirroring or aligning doesn't change the relationship of pixel data to the pixel grid, by default, and you have to actively change the behaviour if unwanted.

I know it's different but I don't think it's necessarily less intuitive than using save-as.
As far as I see it save as was not always there for "saving as a different format", it was there to save ayour current project AS a different PROJECT - useful for making various options or using previous work as a base to do something new. I actually think it was pretty lazy of certain programs to bundle in the exporting of that file to different formats in to the save as function. And, whilst this may be common to some programs, it certainly isn't to all. 
I don't quite understand why you say it is an old-fashioned UI/UX, imo it's actually a more considered choice, with using save-as being an antiquated "choice".

I personally don't find it at a struggle to scroll the extra few lines down from "save as" to "export" in the menu (I certainly don't find it harder to find at all) when I want to export, nor do I find it a hassle to remember to press alt as well as ctr,, shift & s as a shortcut to export my creation to a different file format. I'm not really sure what it is you are asking Serif to "spare us" from.
I actually don't save my work as jpg most of the time. If I'm using affinity to create a file I want it preserved in that format in case I want to make changes to it, or use it to do something new. I do of course want to export it as jpg (or png, etc etc) at various points, but this is a separate exercise to saving my work.
In my opinion it is good that the two separate functions of saving a layer based affinity file, and creating a flattened file format is separated as they are. Export is a perfectly logical choice for creating a jpeg as that is exactly what you are doing - exporting your file to something which is fundamentally different to what it is. I welcome this kind of clarity of function.

I'm not really sure I see why there is any difference from a work flow perspective between choosing  "save as" or choosing "export" when you want to export a jpg from your file anyway... the only thing I can see is force of habit and one additional key modifier - neither of which seem a good enough justification to  present it as a big issue or poor design decision.
I honestly feel like this request boils down to "I'm not used to it being called export instead save-as"... and the perception that this is a wrong choice or somehow creates a stumblingblock to creating jpgs, pngs, etc, flows from that. Choosing export rather than save-as in the (same) menu, or pressing alt as well as shift s is not "inherently any more difficult as an operation, it's only really user habit that may make it so - which really needs to be considered against the reasons why it was done differently, and the fact that it won't actually be the case for eeryone, only a certain group of people. Personally, even having extensively used photoshop, I didn't really have any issue getting accustomed to this difference. This could be because other programs I also use a lot do it already though.
I personally hope Serif don't make this change as I prefer it as it is.
Just my opinion but I thought it worth adding the counter-point to your request.

I know it's different but I don't think it's necessarily less intuitive than using save-as.
As far as I see it save as was not always there for "saving as a different format", it was there to save ayour current project AS a different PROJECT - useful for making various options or using previous work as a base to do something new. I actually think it was pretty lazy of certain programs to bundle in the exporting of that file to different formats in to the save as function. And, whilst this may be common to some programs, it certainly isn't to all. 
I don't quite understand why you say it is an old-fashioned UI/UX, imo it's actually a more considered choice, with using save-as being an antiquated "choice".

I personally don't find it at a struggle to scroll the extra few lines down from "save as" to "export" in the menu (I certainly don't find it harder to find at all) when I want to export, nor do I find it a hassle to remember to press alt as well as ctr,, shift & s as a shortcut to export my creation to a different file format. I'm not really sure what it is you are asking Serif to "spare us" from.
I actually don't save my work as jpg most of the time. If I'm using affinity to create a file I want it preserved in that format in case I want to make changes to it, or use it to do something new. I do of course want to export it as jpg (or png, etc etc) at various points, but this is a separate exercise to saving my work.
In my opinion it is good that the two separate functions of saving a layer based affinity file, and creating a flattened file format is separated as they are. Export is a perfectly logical choice for creating a jpeg as that is exactly what you are doing - exporting your file to something which is fundamentally different to what it is. I welcome this kind of clarity of function.

I'm not really sure I see why there is any difference from a work flow perspective between choosing  "save as" or choosing "export" when you want to export a jpg from your file anyway... the only thing I can see is force of habit and one additional key modifier - neither of which seem a good enough justification to  present it as a big issue or poor design decision.
I honestly feel like this request boils down to "I'm not used to it being called export instead save-as"... and the perception that this is a wrong choice or somehow creates a stumblingblock to creating jpgs, pngs, etc, flows from that. Choosing export rather than save-as in the (same) menu, or pressing alt as well as shift s is not "inherently any more difficult as an operation, it's only really user habit that may make it so - which really needs to be considered against the reasons why it was done differently, and the fact that it won't actually be the case for eeryone, only a certain group of people. Personally, even having extensively used photoshop, I didn't really have any issue getting accustomed to this difference. This could be because other programs I also use a lot do it already though.
I personally hope Serif don't make this change as I prefer it as it is.
Just my opinion but I thought it worth adding the counter-point to your request.

I know it's different but I don't think it's necessarily less intuitive than using save-as.
As far as I see it save as was not always there for "saving as a different format", it was there to save ayour current project AS a different PROJECT - useful for making various options or using previous work as a base to do something new. I actually think it was pretty lazy of certain programs to bundle in the exporting of that file to different formats in to the save as function. And, whilst this may be common to some programs, it certainly isn't to all. 
I don't quite understand why you say it is an old-fashioned UI/UX, imo it's actually a more considered choice, with using save-as being an antiquated "choice".

I personally don't find it at a struggle to scroll the extra few lines down from "save as" to "export" in the menu (I certainly don't find it harder to find at all) when I want to export, nor do I find it a hassle to remember to press alt as well as ctr,, shift & s as a shortcut to export my creation to a different file format. I'm not really sure what it is you are asking Serif to "spare us" from.
I actually don't save my work as jpg most of the time. If I'm using affinity to create a file I want it preserved in that format in case I want to make changes to it, or use it to do something new. I do of course want to export it as jpg (or png, etc etc) at various points, but this is a separate exercise to saving my work.
In my opinion it is good that the two separate functions of saving a layer based affinity file, and creating a flattened file format is separated as they are. Export is a perfectly logical choice for creating a jpeg as that is exactly what you are doing - exporting your file to something which is fundamentally different to what it is. I welcome this kind of clarity of function.

I'm not really sure I see why there is any difference from a work flow perspective between choosing  "save as" or choosing "export" when you want to export a jpg from your file anyway... the only thing I can see is force of habit and one additional key modifier - neither of which seem a good enough justification to  present it as a big issue or poor design decision.
I honestly feel like this request boils down to "I'm not used to it being called export instead save-as"... and the perception that this is a wrong choice or somehow creates a stumblingblock to creating jpgs, pngs, etc, flows from that. Choosing export rather than save-as in the (same) menu, or pressing alt as well as shift s is not "inherently any more difficult as an operation, it's only really user habit that may make it so - which really needs to be considered against the reasons why it was done differently, and the fact that it won't actually be the case for eeryone, only a certain group of people. Personally, even having extensively used photoshop, I didn't really have any issue getting accustomed to this difference. This could be because other programs I also use a lot do it already though.
I personally hope Serif don't make this change as I prefer it as it is.
Just my opinion but I thought it worth adding the counter-point to your request.

Why:
Vector brushes are great, but can be quite frustrating when using them for certain purposes, especially vector image brushes. Quite often you will have a nice image that you want to draw along the path, set up just how you want it... then Affinity goes and stretches it.
This is particularly an issue when you are creating brushes that represent real things, like walls, or cliffs. You want a decent amount of variation and so need a decent length image to do so.
It's fine if you are doing really long paths where the repeat is numerous and the stretch can be spread out, or have lines that are very close to exact multiples of your image, but other than that you will find your paths just look totally different, which is often not at all what you want, and when you have short paths, squeezing one whole repetition of the image in to the path can look really wrong/ugly.
What:
The ability to set a vector brush to just repeat the image and cut off at whatever point along the image the path happens to end (ie. to not stretch the image at all) would be a really helpful addition. Granted this would mean that closed path ends would not meet seamlessly, but that is a trade off that is perfectly acceptable for the benefit of consistent image representation and not relevant in all use cases. Maybe another option could even allow it to be set to stretch only if closed.
Image attached for clarity.
Lastly I did search for similar posts, but apologies if this has come up already.

 

To add to the corner issue above, this is even more frustrating if you are working with compound curves, because you actually can't add the extra control points to your shapes (or rather you can, but the rendering of the stroke on the compound path will just ignore them) meaning you are forced to destructively convert the compound path to curves, and then add your control points.
It's not.... great.

I've previously requested an opacity control for each fill/stroke, regardless of the type of fill/stroke
 

It would be really handy for certain use cases if textured intensity and especially textured image vector brushes could be set to instead of trying to fit a whole number of repetitions within your line,  just cut off the image wherever it happens to finish along a repetition.
The stretching to fit can play merry hell when you have things like a rocky wall that you want to have a good level of variation (so a long image and repeat zone) but also look the same on all your linework regardless of length. Stretching can leave you with wildly different looking lines, especially on shorter ones which are 1.5 or less than 1 repetition long, with the only recourse being to adjust the repeat areas of each line individually.
I'd almost say for textured image brushes this is probably a default behaviour you would want.

I'd like to bump this post. This feature would be crazy useful for designing maps and game assets. Please consider adding this!

It would be really handy for certain use cases if textured intensity and especially textured image vector brushes could be set to instead of trying to fit a whole number of repetitions within your line,  just cut off the image wherever it happens to finish along a repetition.
The stretching to fit can play merry hell when you have things like a rocky wall that you want to have a good level of variation (so a long image and repeat zone) but also look the same on all your linework regardless of length. Stretching can leave you with wildly different looking lines, especially on shorter ones which are 1.5 or less than 1 repetition long, with the only recourse being to adjust the repeat areas of each line individually.
I'd almost say for textured image brushes this is probably a default behaviour you would want.

This is another good observation. In my case, I can store the download on a separate (very large drive) along with the actual application installation, and only have one download of something usually shared, i.e. brushes. Not everyone is, or can be, set up like this. But yes, when opened in each application, the resources are installed in a separate .propcol file per application. The more resources one accumulates, the more the OS drive gets eaten up and no one wants to have to reinstall their entire system to a new larger drive every so often just for a few brushes.
Admittedly, I am not a programmer; however, I hope this is entire thread is taken to be constructive and not whiny. Windows has always been known for inefficient use of hardware resources, lovingly known as bloatware. Microsoft moving to the cloud is more of their way to continue this bad practice than to rise above it. Unfortunately, application writers, in order to be compatible with windows, get caught in this abyss. 

Clear history would still be really nice though, as it would allow clearing the history from memory whilst working on a doc to help performance.

I'm bumping this, cuz I'd like to have a randomized perlin noise filter too.

The perlin noise filter and such other filters should ideally be tileable seamlessly. In it's current form they are not usable for shader work. I'm forced to use PS or any other seamless perlin noise generator until then.

Hallo,
I think he means the „live paint bucket“. For exampel its showing here 
 
This is a Great Tool. I am waiting for this Tool in affinity Designer.