GIMP 2.10, Windows 64-bit

I seem to be getting the following errors when using some brushes:

"Unable to read tile data from swap: No such file or directory (0/xxx bytes read) --"

twice, followed by

"Unable to read tile data from swap: No error (0/xxx bytes read) --"

etc. followed by "Too many error messages!"
"Messages are redirected to stderr."

Any ideas on what is going wrong here for me?

Thanks, Partha

PS: I was not getting these swap errors for sometime now and suddenly in the final release, they are back again.

On Wed, May 2, 2018 at 2:47 AM, Ell wrote:

On Tue, 1 May 2018 16:17:12 -0400 Partha Bagchi wrote:

GIMP 2.10, Windows 64-bit

I seem to be getting the following errors when using some brushes:

"Unable to read tile data from swap: No such file or directory (0/xxx bytes read) --"

twice, followed by

"Unable to read tile data from swap: No error (0/xxx bytes read) --"

etc. followed by "Too many error messages!"
"Messages are redirected to stderr."

Any ideas on what is going wrong here for me?

Thanks, Partha

PS: I was not getting these swap errors for sometime now and suddenly in the final release, they are back again.

How long ago did it start? Does disabling the separate paint thread fixes this? It can be disabled by setting the GIMP_NO_PAINT_THREAD environment variable.

--
Ell

Thanks for responding Ell!

It started again after the final release. It was not there in RC1. I didn't know about the env. variable. I'll check it out and let you know.

This may be a affect of the transition from gegl 0.3 to 0.4?

In the past, it was related to complicated images with high resolution and usually setting GEGL_CACHE_SIZE to 2048 or thereabouts fixed it. Now, it does not.

Partha

On Wed, May 2, 2018 at 6:22 AM, Partha Bagchi wrote:

On Wed, May 2, 2018 at 2:47 AM, Ell wrote:

On Tue, 1 May 2018 16:17:12 -0400 Partha Bagchi wrote:

GIMP 2.10, Windows 64-bit

I seem to be getting the following errors when using some brushes:

"Unable to read tile data from swap: No such file or directory (0/xxx bytes read) --"

twice, followed by

"Unable to read tile data from swap: No error (0/xxx bytes read) --"

etc. followed by "Too many error messages!"
"Messages are redirected to stderr."

Any ideas on what is going wrong here for me?

Thanks, Partha

PS: I was not getting these swap errors for sometime now and suddenly in the final release, they are back again.

How long ago did it start? Does disabling the separate paint thread fixes this? It can be disabled by setting the GIMP_NO_PAINT_THREAD environment variable.

--
Ell

Thanks for responding Ell!

It started again after the final release. It was not there in RC1. I didn't know about the env. variable. I'll check it out and let you know.

This may be a affect of the transition from gegl 0.3 to 0.4?

In the past, it was related to complicated images with high resolution and usually setting GEGL_CACHE_SIZE to 2048 or thereabouts fixed it. Now, it does not.

Partha

Hi Ell,

I did the following. I set the following environment variables: GEGL_SWAP=C:\Users\partha\AppData\Local\Temp\gegl GIMP_NO_PAINT_THREAD="Y"

It didn't make any difference. Matter of fact, GEGL_SWAP was unused. So, I removed it and reran GIMP. No change.

Thanks, Partha

On Wed, May 2, 2018 at 9:59 AM, Ell wrote:

On Wed, 2 May 2018 09:16:46 -0400 Partha Bagchi wrote:

It started again after the final release. It was not there in RC1.

So it only started at some point after RC1, but before 2.10? (days? weeks?) I'm trying of think of things that changed during that time that might have caused this. Did you change something on your end?

No, I mean that the change was related to the final release 2.10.0 and not before. I had no reports prior to final release.

My changes are cosmetic. For example, I modify ./app/widgets/gimppanedbox.c
// #define INSTRUCTIONS_TEXT _("You can drop dockable dialogs here") #define INSTRUCTIONS_TEXT _("")

I don't modify anything in babl or gegl. My compiler is gcc 7.1

This may be a affect of the transition from gegl 0.3 to 0.4?

Not likely, especially if it already happened before 2.10. The 0.4 switch happened right before the release.

See above. As you say, 0.4 switch was literally before the final release. In fact gimp.pc.in was changed after the release.

In the past, it was related to complicated images with high resolution and usually setting GEGL_CACHE_SIZE to 2048 or thereabouts fixed it. Now, it does not.

This sounds like you might have ran out of cache and swap space, in which case you'd start getting write errors. These are read errors, which are much more surprising.

You are right. These are read errors.

I did the following. I set the following environment variables: GEGL_SWAP=C:\Users\partha\AppData\Local\Temp\gegl GIMP_NO_PAINT_THREAD="Y"

It didn't make any difference.

Ok, so it's not the separate paint thread. That's a good thing :) What's the rest of your GEGL setup like? Are you using any other environment variables? What's the thread count?

My GEGL compilation of simply what environment variables? I only have one GEGL variable active now: gpu usage. My configure from the config.log is:

$ ./configure --prefix=/opt/gimp/std --build=x86_64-w64-mingw32

CPPFLAGS=-I/opt/include -I/usr/python/include -I/opt/SuiteSparse/include LIBS=-L/opt/lib -L/usr/python/Lib -L/opt/SuiteSparse/lib --disable-docs --without-libavformat --without-sdl --enable-workshop build_alias=x86_64-w64-mingw32 CC=gcc CFLAGS=-O3 -ffast-math -ftree-vectorize CXX=g++ CXXFLAGS=-std=c++14 -DMS_WIN64 -O3 -ffast-math -ftree-vectorize
PKG_CONFIG_PATH=/opt/lib/pkgconfig:/usr/python/Lib/pkgconfig:/opt/share/pkgconfig:/opt/gimp/libmypaint/lib/pkgconfig:/opt/gimp/std/lib/pkgconfig --no-create --no-recursion

My thread count is 8. I've tried with thread count set to 1 with the same result.

Matter of fact, GEGL_SWAP was unused. So, I removed it and reran GIMP. No change.

Do you mean that GEGL wasn't using the swap? Can you use the dashboard to see if anything "interesting" is going on while this happens? Is the cache full? Is the swap nearly full? Do the reported cache/swap size limits make sense?

OK. When I start the dashboard, I have the following: Cache:

Occupied: 0 bytes (0%)

Limit: 7.9 GiB

Swap:

Occupied: 0 bytes (0%)

Size: 0 bytes (0%)

Limit: 114.7 GiB

CPU (0%)

Opened image (RGB Color 16-bit gamma integer, MelissaRGB 1 layer) 7378x4924 (D800 36MP image)
Duplicate Layer.
Dashboard:
Cache:

Occupied: 751.6 MiB (9%) Limit: 7.9 GiB

Swap (no change)

Start painting on the layer: Cache:

Occupied: 818.7 MiB (10%)

Limit: 7.9 GiB

Swap:

Occupied: 512.0 Kib (0%)

Size: 4.0 MiB (0%)

Limit: 114.7 GiB

CPU (0%)

But, we have: GEGL Message

unable to read tile data from swap: No such file or directory (0/130568 bytes read) --

GEGL Message

unable to read tile data from swap: No such file or directory (0/130568 bytes read) --

GEGL Message

unable to read tile data from swap: No error (0/130568 bytes read) --

Too many error messages etc.

--
Ell

Thanks,
Partha

On Wed, May 2, 2018 at 2:18 PM, Øyvind Kolås wrote:

On Wed, May 2, 2018 at 4:36 PM, Partha Bagchi wrote:

My GEGL compilation of simply what environment variables? I only have one GEGL variable active now: gpu usage.

GPU usage meaning OpenCL?

I was using the following:
GEGL_USE_OPENCL=gpu;
Is that what you mean?

GEGL has stopped enabling opencl by defult now, since GEGL-0.3.24 of 2017-11-24 it no longer being enabled by default since it relies on good results from the varying quality different opencl implementations,.. may also have generic race conditions resulting from new code not manifest during regular testing either, so trying without OpenCL enabled.

/pippin

I removed the above environment variable but no change with my 36MP image. The moment I put the brush on the screen, I get the error messages above.

Then I experimented with some more pictures and it seems to be related to the size of the image.

I open a 1 megabyte (MB), and 4MB image and no error. Then I open a 74MB image without error. But when I opened an 300 MB Tiff, I started getting the error.

I repeated the experiment with GEGL_CACHE_SIZE = 2048 with the same result.

For all all images, I first fit to window > duplicate layer > paint on duplicate layer.

Thanks,
Partha

On Wed, May 2, 2018 at 3:04 PM, Partha Bagchi wrote:

On Wed, May 2, 2018 at 2:18 PM, Øyvind Kolås wrote:

On Wed, May 2, 2018 at 4:36 PM, Partha Bagchi wrote:

My GEGL compilation of simply what environment variables? I only have

one

GEGL variable active now: gpu usage.

GPU usage meaning OpenCL?

I was using the following:
GEGL_USE_OPENCL=gpu;
Is that what you mean?

GEGL has stopped enabling opencl by defult now, since GEGL-0.3.24 of 2017-11-24 it no longer being enabled by default since it relies on good results from the varying quality different opencl implementations,.. may also have generic race conditions resulting from new code not manifest during regular testing either, so trying without OpenCL enabled.

/pippin

I removed the above environment variable but no change with my 36MP image. The moment I put the brush on the screen, I get the error messages above.

Then I experimented with some more pictures and it seems to be related to the size of the image.

I open a 1 megabyte (MB), and 4MB image and no error. Then I open a 74MB image without error. But when I opened an 300 MB Tiff, I started getting the error.

I repeated the experiment with GEGL_CACHE_SIZE = 2048 with the same result.

For all all images, I first fit to window > duplicate layer > paint on duplicate layer.

Thanks,
Partha

One additional piece of data that may or may not be relevant. The When I

change the layer to mode something other than normal and change it back, the painting shows up fine.

Here is the before image: https://www.partha.com/downloads/GIMP/Screen-painting-before.jpg and here is the after switching layer modes to something and back to normal: https://www.partha.com/downloads/GIMP/Screen-painting-after.jpg

On Wed, May 2, 2018 at 3:49 PM, Ell wrote:

On Wed, 2 May 2018 15:04:01 -0400 Partha Bagchi wrote:

On Wed, May 2, 2018 at 2:18 PM, Øyvind Kolås wrote:

GEGL has stopped enabling opencl by defult now, since GEGL-0.3.24 of 2017-11-24 it no longer being enabled by default since it relies on good results from the varying quality different opencl implementations,.. may also have generic race conditions resulting from new code not manifest during regular testing either, so trying without OpenCL enabled.

/pippin

I removed the above environment variable but no change with my 36MP image. The moment I put the brush on the screen, I get the error messages above.

Then I experimented with some more pictures and it seems to be related to the size of the image.

I open a 1 megabyte (MB), and 4MB image and no error. Then I open a 74MB image without error. But when I opened an 300 MB Tiff, I started getting the error.

I repeated the experiment with GEGL_CACHE_SIZE = 2048 with the same result.

For all all images, I first fit to window > duplicate layer > paint on duplicate layer.

My guess is that this is related to the zoom level (being

You may be right! I changed the zoom level to 51% and didn't see that error. I'll have to experiment some more of course.

For GEGL, I'll git pull and rebuild to see what the effect is.

Note that the actual bug was the swap being used in the first place. I'm still not sure why you're getting read errors, though. Since the swap shouldn't be used anymore (in this particular case) after the above commit, the errors will probably go away, but the issue causing them might still be there. I'd try to set a very low cache size, in order to force the swap to become very active, and see if you're getting any more errors.

I should do this after update gegl and gimp, correct?

--
Ell

Thanks!
Partha

On Wed, May 2, 2018 at 3:58 PM, Ell wrote:

On Wed, 2 May 2018 15:56:12 -0400 Partha Bagchi wrote:

On Wed, May 2, 2018 at 3:49 PM, Ell wrote:

Note that the actual bug was the swap being used in the first place. I'm still not sure why you're getting read errors, though. Since the swap shouldn't be used anymore (in this particular case) after the above commit, the errors will probably go away, but the issue causing them might still be there. I'd try to set a very low cache size, in order to force the swap to become very active, and see if you're getting any more errors.

I should do this after update gegl and gimp, correct?

Yep.

--
Ell

Sounds good.

I think your hypothesis that it's related to the zoom level may be correct. I restarted GIMP with no GEGL environment variables. I opened image > duplicated layer. I set the zoom level to 50.1% and I saw the same artifacts. Then I increased the zoom to 50.5% and it went away.

You realize that for large images, it would be unwieldy to be painting at that zoom level?

Thanks again to you and pippin for resolving this.

Partha

PS: Did you see the screenshots I posted?