In D8868#171106, @dkazakov wrote:

So you mean that 10-15 period value looks much better for you?

In D8868#170458, @dkazakov wrote:

The brush FPS is now automatically adjusted in range 12.5...100 FPS depending on the current speed of the brush. And, yes, it is not in sync with the display update rate, because display update should also update brush outline.

Since the brush isn't updating every frame anymore and since the desktop manager (on Windows) is in sync with the display's refresh rate, this gives the impression of lower performance when using small brushes, even if performance with very big brushes might now be higher.

I'll try to think about it. Though I'm not sure I know what solution I can make for it... The brush updates were never in sync with display updates. They were just quick enough to "look" like being in sync :)

I added a wishlist item about this a short time ago, which I assume you may have already seen.

Both cases of kritarc accesses I mentioned are now fixed with commits e97f50912718f114686593d365a275ce86df61ac (krita/3.2) and 1da3b038dcd824c8b138bfdee6aa3aa0262b7de5 (master).

In T5519#108190, @rempt wrote:

Hm, that's interesting. Have you checked where that happens?

While I'd say that this is unrelated to the linked bug report, I think it's worth a mention that it's slower to use the move tool with the layer docker visible.
When moving while the layer docker is visible, kritarc is accessed at fairly regular intervals, leading to a brief pause in motion.
(This happens in 3.2 and master)

In D6431#124086, @rempt wrote:

The cropRect from G'MIC is a normalized rectangle. m_view->image()->bounds() is (0,0 canvasWidth x canvasHeight) (hopefully, or else my patch is wrong).
From how it's written, I imagine the intended default was (0,0 1.0x1.0).

What we get from gmic was, afair, a rectangle normalized to 0,0 1.0x1.0 -- so in prepareCroppedImages, that was multiplied with the dimensions of the layer.

That is correct.
Any potential problem here would be from the error case, where we will no longer have a normalized rectangle.

It seems to work identically to the old plug-in now.

In D6431#123202, @dkazakov wrote:

From the mere reading of your explanation it looks as if GMic tries to read data directly from the data manager, because the MoveTool introduces (x,y) offset for a layer and, therefore, paint device, which is then handled by the methods of KisPaintDevice and iterators. If one uses device->readBytes/readPlanarBytes(), then everything should be fine.

I don't feel that the changes to kis_import_qmic_processing_visitor.cpp and kis_qmic_simple_convertor.cpp should be considered valid.

Indeed, your guess was correct and the KisAlgebra2D way of doing it works just fine (I see that mapToRect is not currently available in the stable branch, though).

Closed by R37:eec26a6880377f804f3b178c0a4e133a198acbc4 (krita/3.2) and R37:e9a71be36a7f254c5d23bf2bf5a91e358fda735c (master)

Fixes issue where the canvas would still shrink on one axis.

Regarding bug 376214 (layer sometimes says "group not editable")...
There are a few other bugs which I imagine could be associated with this one. In case they help nail it down, here are the ones I'm thinking of:

I wasn't sure either. I'd actually prefer to list the alpha channel in all color spaces.
Is there any place you'd like me to post about this so we can get opinions?

(I think this should have been automatically closed by R37:aa3e7b214ac6749f18ab80115a510ac33923ddf8, but it wasn't.)

This also occurs with filter and transform masks.
It seemed like refreshGraphAsync() (called from MoveStrokeStrategy::finishStrokeCallback()) was only walking down the layer stack when I had a look at it -- could that be the problem?

KisPaintopBox::setCurrentPaintopAndReload() gets called twice when you select a brush (2 resourceSelected() signals).
Putting this at the top of it fixes both bugs for me, but I imagine that it's probably far better to make sure it only gets called once.

if(m_resourceProvider->currentPreset() == preset){
    return;
}

I don't have commit access.

That looks good! I'll close the revision. [Edit : I thought "Abandon Revision" would do that, but it seems not. Is there any preferred procedure for when a patch is accepted or no longer needed?]