lepr

Use a vector rectangle as a helper. create a vector rectangle and rotate it to match the arrow's direction perform one of the following options: nest the raster object inside the rotated rectangle, use Move Tool with 'Lock Children' disabled to stretch the rectangle, release the raster object from the rectangle don't nest and instead enable Move Tool's 'Transform Objects Separately', select the rotated rectangle first and then also the raster object, stretch

My video demonstrates there is more wrong than just redraw - the result of Rasterise is also wrong. Is that logged, too?

You are no moron. The Group case is OK and working as expected. The Layer case strongly smells of bug: when dragging one Ellipse, the bounding box and centre of the parent Layer, instead of the sibling Ellipse, is being considered as a snapping target. The weirdness does not happen in 2.4.2. It does happen in the current beta of 2.6.3. This video should make the misbehaviour clearer: badsnap.mp4

It was my solution. PixelPest was providing a video of it because someone misunderstood/misperformed the two steps and claimed it didn't work.

Are you implying that MEB can perfectly imitate James Ritson?

The word was “inherent”, not “inherited”.

The good old argument from authority. Oh dear, that often ends badly.

The message really means select either an item in the History panel or an item in the Snapshots panel.

I merely gave an example of how the words in a UI do not necessarily reveal the inner workings of software, and gave a hypothetical example. It's such a simple concept, that I have to wonder if you are pretending to be an idiot once again. (Since you've asked about inverting a mask when the mask does not yet exist: hypothetically, an Invert Mask command could result in a 'full' mask being created then inverted.) As I already wrote: "There is a reason (hint: transforms and ppi) that I do agree with you that an Adjustment always has a built-in mask, even when that mask is 'full' and not thumbnailed in the Layers panel." Do you see yet? I agreed with you about the actual situation in Affinity!

The words of the UI do not prove what the software is doing behind the scenes. For example, it is possible that Fill Mask actually results in an Adjustment’s reference to a mask being set to null. Having said that, that's not what I think happens. There is a reason (hint: transforms and ppi) that I do agree with you that an Adjustment always has a built-in mask, even when that mask is 'full' and not thumbnailed in the Layers panel. My point is that words in a UI are not necessarily true descriptions of operations behind the scenes, and these words do not prove anything.

There is a primitive destructive Auto Levels command (with button in the main toolbar) that you can try, otherwise you need to manually, and tediously, fiddle with each channel in a nondestructive Levels Adjustment or Curves Adjustment.

Now you demonstrate that you’ve completely failed to understand my message.

It is unsafe to assume the internal mechanisms of the app from words in the UI.

In Layers panel, right-click the Adjustment's mask thumbnail and pick Fill Mask. (Not available in v2.4.2 and earlier.)

This is a separate topic. Both topics are about Displacement filter, but very different topics.

It clearly is a bug. Consider reporting it in the appropriate bugs forum to increase the probability of a fix.

It isn't only theory. It does happen when the target is not already a Pixel object; for example, a vector Rectangle or a Group. That is the scenario I was talking about. My bad for not considering the case of a Pixel target.

cmd+a (ctrl+a on Win) does that if, and only if, Edit All Layers is disabled at bottom left of Layers panel. Not saying that is an adequate solution, just letting you know it exists.

It's a bug. Serif never give time frames for bug fixes and some have lingered for a decade. You could try selecting the Warp Group and doing Convert To Curves, but that can produce other distortions.

Here's a video showing the bug when an object inside a Warp Group is reduced in size. At the end, I rasterise the Warp Group to show that there is more to the bug than just a screen refresh problem. warp group bug.mp4

A Live Filter is displayed acting on a mipmap rendering of a nondestructive rasterisation of its target. The target can be a parent of the Live Filter, or the scene underlying the Live Filter. That's not what happens in my experience. When a destructive filter is invoked, its unaffected target is instantly destructively rasterised to an unscaled, unskewed and unrotated Pixel object with the pixel density of the document and aligned with the document pixel grid, as if the Rasterise command had been invoked. Then a preview of the filter acting on a mipmap rendering of the Pixel object, not the full scale Pixel object, is displayed (and that will normally appear identical to the live version of the filter at a given view zoom). If the 'Apply' button is clicked, the full scale Pixel object gets destructively modified by the filter. If the 'Cancel' button is clicked, the Pixel object remains unaffected, and an Undo must still be performed by the user if the document is to be returned to the state before the filter was invoked.

Not sure why you wrote all that in response to my post. There is a bug in the live Displacement filter.

The preview of the Displacement destructive filter (and the other destructive filters) is also mipmap rendered but is free of glitching. There is a bug in the live filter, not a "sensitivity".

control + left click on a Mac is normally equivalent to right click

With Move Tool active, select all the required Curve objects Flip Vertical Switch to Node Tool, press cmd+a (ctrl+a on Windows) to select all nodes of the Curve objects Flip Vertical