I'd be interested to see a more detailed profiling inside paintGL and see what's actually changed...

Also, when writing the commit message, please try to keep the first line short and add a bit of detail to the body. Here is a nice guide to do it: https://chris.beams.io/posts/git-commit/#seven-rules
(It's not a requirement to follow it exactly, but it does make the commit messages clearer.)

At the end of the commit message, please add a line Differential Revision: https://phabricator.kde.org/D8280 to link the commit back to this Phabricator revision. Please also do the same for your future commits. It helps us to trace the changes. :)

@alvinhochun I did more tests on two Macs and the time difference seems to come from glDrawArrays.

I also suspect that having much less tiles (i.e. 1 -5 to > 100) destresses the whole tile management pipeline and mutexing.

Here are the basic results with a smaller canvas (1500 x 1500).

First on a iMac 5K:

And here on a MacBook Pro:

In both cases, the right side is the 2048 texture tile size. As you can see, the hit is inside glDrawArrays and the driver implementation. On the other hand, there's not more time spent in glTexSubImage2D for the larger tile size. Both main threads took about 60% of total.

Now, what confused me in the measures above is that paintGL as a whole did not take less time. Don't ask me to explain, but this only seems to happen for larger images. I did one more test with a 4000 by 4000 canvas. Here's the result:

For smaller canvases the new texture size means that there will be only one tile and one texture that is drawn which in terms of the drawing process this is fast (as long as we don't do any kind of incremental updates on a single buffered context).

It's hard to track down all the implications of this change performance-wise, but I think it should usually be a small performance improvement.

pushed to master.

https://commits.kde.org/krita/7e81dc12f5e38f2c8254164392cf9a2aa1de0ddd

@dkazakov Just recognized that this change has implications for the pool sizes defined in kis_texture_tile_info_pool.h:

const int minPoolChunk = 32; // 8 MiB (default, with tilesize 256)
const int maxPoolChunk = 128; // 32 MiB (default, with tilesize 256)
const int freeThreshold = 64; // 16 MiB (default, with tilesize 256)

What unsettles me a bit is that I just a that m_maxAllocations went up to 35 while drawing in my tests here. With the old tile size (256), this meant allocating 256 * 256 * 4 * 35 = 8,75 MB, while with 2048 as tile size, this is 2048 * 2048 * 4 * 35 = 560 MB.

We might change the defs to not use numbers but rely on the given texture size, something like:

const int minPoolSize = 8 * 1024 * 1024; // 8 MiB
const int freeThresholdSize = 16 * 1024 * 1024; // 16 MiB

class KisTextureTileInfoPoolSingleSize
{
public:
    KisTextureTileInfoPoolSingleSize(int tileWidth, int tileHeight, int pixelSize)
        : m_chunkSize(tileWidth * tileHeight * pixelSize),
          m_freeThreshold(freeThresholdSize / m_chunkSize),
          m_pool(m_chunkSize, std::max(1, minPoolSize / m_chunkSize)),
          m_numAllocations(0),
          m_maxAllocations(0),
          m_numFrees(0)
    {
    }

Reverted.

https://commits.kde.org/krita/a7ba06f0634a5225821f9444576f77a779a6a3ec