Hi Simon, hi.

Simon Walter - 24.07.24, 09:23:45 CEST:
> > Have they ever removed the limitation that pixel coordinates have to
> > fit into 16-bit words?
> >
> > This may have mad sense in the old days, but it was a real hindrance
> > when I wanted a large scroll region.
>
> Let me understand this.
>
> Are you saying that the way the screen is/was drawn, the placing of the
> pixels, had the coordinates using 16 "addresses" so to speak? Does that
> also limit the area? I will not attempt the math this early in the
> morning.
>
> How does this affect scroll region... oh, I see. The scrollable area may
> be considerably larger than the "viewport" - if I may call it that.
>
> I would assume that such a limitation no longer exists. I wonder if it
> was a QT limitation back then or a KDE library / kwin limitation.

I was completely oblivious of any 16 bit limitation for pixel coordinates
within KDE software or Qt based software so far.

On one hand I wonder why more? I have yet to see a 65536x65536 pixel
display. However… if you combine a lot of displays into a wall of displays
you can exceed that limit. And also modern cameras have crazy amount of
megapixels. And if you like to have loss free zooming into an image, you
may need a very high resolution as well.

So, yes… even if Bill Gates may not even have said it: 640 KiB of RAM is
not enough for everyone.

I tried a simple test with Krita as I would assume that they do not have
this limit anymore. But it did not go well. Even for "just" 50000x50000 32
bit RGBA pixels – which is even within 16 bit pixel coordinate boundary –
it said it will use 9,3 GiB in a single layer. However…

it almost ate up all 50 GiB of swap and a good part of 32 GiB of RAM!

And then this:

[16268.449686] kscreen_backend[6325]: segfault at c ip 00007faf524a42a9 sp 00007fff2716f3c0 error 4
[16268.449707] xembedsniproxy[6361]: segfault at c ip 00007fcc80afd2a9 sp 00007ffd15a05e20 error 4
[16268.449886] gmenudbusmenupr[6389]: segfault at c ip 00007f13d40fd2a9 sp 00007ffdcb6047d0 error 4 in libQt5XcbQpa.so.5.15.13[7f13d40c3000+cd000] likely on CPU 5 (core 2, socket 0)
[16268.449906] Code: e9 fe fc ff ff 0f 1f 40 00 48 8b 7b 20 8b 54 24 44 8b 74 24 4c e8 e7 63 fc ff 48 8b 7b 20 31 d2 89 c6 e8 ea 6a fc ff 49 89 c6 <8b> 40 0c 85 c0 0f 85 73 04 00 00 e8 f7 13 fd ff 0f b6 40 10 84 c0
[16268.451892] in libQt5XcbQpa.so.5.15.13[7faf5246a000+cd000]
[16268.452900] in libQt5XcbQpa.so.5.15.13[7fcc80ac3000+cd000]
[16268.453748] likely on CPU 1 (core 0, socket 0)
[16268.454437] likely on CPU 10 (core 5, socket 0)


[16268.456971] Code: e9 fe fc ff ff 0f 1f 40 00 48 8b 7b 20 8b 54 24 44 8b 74 24 4c e8 e7 63 fc ff 48 8b 7b 20 31 d2 89 c6 e8 ea 6a fc ff 49 89 c6 <8b> 40 0c 85 c0 0f 85 73 04 00 00 e8 f7 13 fd ff 0f b6 40 10 84 c0
[16268.457702] Code: e9 fe fc ff ff 0f 1f 40 00 48 8b 7b 20 8b 54 24 44 8b 74 24 4c e8 e7 63 fc ff 48 8b 7b 20 31 d2 89 c6 e8 ea 6a fc ff 49 89 c6 <8b> 40 0c 85 c0 0f 85 73 04 00 00 e8 f7 13 fd ff 0f b6 40 10 84 c0
[16268.462488] vlc[1523]: segfault at c ip 00007f58bd0fd2a9 sp 00007f58be3fe990 error 4 in libQt5XcbQpa.so.5.15.13[7f58bd0c3000+cd000] likely on CPU 10 (core 5, socket 0)
[16268.463377] Code: e9 fe fc ff ff 0f 1f 40 00 48 8b 7b 20 8b 54 24 44 8b 74 24 4c e8 e7 63 fc ff 48 8b 7b 20 31 d2 89 c6 e8 ea 6a fc ff 49 89 c6 <8b> 40 0c 85 c0 0f 85 73 04 00 00 e8 f7 13 fd ff 0f b6 40 10 84 c0
[16268.463972] kiod5[7321]: segfault at c ip 00007f9fdcafd2a9 sp 00007ffc9242bab0 error 4 in libQt5XcbQpa.so.5.15.13[7f9fdcac3000+cd000] likely on CPU 13 (core 6, socket 0)
[16268.465489] Code: e9 fe fc ff ff 0f 1f 40 00 48 8b 7b 20 8b 54 24 44 8b 74 24 4c e8 e7 63 fc ff 48 8b 7b 20 31 d2 89 c6 e8 ea 6a fc ff 49 89 c6 <8b> 40 0c 85 c0 0f 85 73 04 00 00 e8 f7 13 fd ff 0f b6 40 10 84 c0
[16268.469693] kclockd[6470]: segfault at c ip 00007fce8defd2a9 sp 00007ffd3390f9d0 error 4 in libQt5XcbQpa.so.5.15.13[7fce8dec3000+cd000] likely on CPU 2 (core 1, socket 0)
[16268.470834] Code: e9 fe fc ff ff 0f 1f 40 00 48 8b 7b 20 8b 54 24 44 8b 74 24 4c e8 e7 63 fc ff 48 8b 7b 20 31 d2 89 c6 e8 ea 6a fc ff 49 89 c6 <8b> 40 0c 85 c0 0f 85 73 04 00 00 e8 f7 13 fd ff 0f b6 40 10 84 c0
[16268.474601] nextcloud[6457]: segfault at c ip 00007f5d2a67e2a9 sp 00007ffe376e15d0 error 4 in libQt5XcbQpa.so.5.15.13[7f5d2a644000+cd000] likely on CPU 3 (core 1, socket 0)
[16268.475957] Code: e9 fe fc ff ff 0f 1f 40 00 48 8b 7b 20 8b 54 24 44 8b 74 24 4c e8 e7 63 fc ff 48 8b 7b 20 31 d2 89 c6 e8 ea 6a fc ff 49 89 c6 <8b> 40 0c 85 c0 0f 85 73 04 00 00 e8 f7 13 fd ff 0f b6 40 10 84 c0
[…]

Talk about stable software! *Other* processes crashed. Krita was still
running! *Other* *unrelated* processes crashed!? Are you even kidding me?

From above output I conclude Qt library libQt5XcbQpa.so messed up its
internal state, affecting other processes that use it. Now I guess
unfortunately no Qt developer is reading this. Another bug report I
could open.

Under memory constraints it shows. Under memory constraints you can
a lot more easily discern on actual quality of an application, a library,
a kernel than with a lot of other conditions.

I wonder why the OOM killer had not kicked in.

So sorry, unless I add another maybe 100 GiB or more of swap I cannot even
test anything beyond 65536x65536 pixels. And maybe even then these crashes
may happen. There was still no OOM killer kicking in so I assume that with
bug free software no crash would have happened at this point.

And mind you, this is the very same power house laptop, that ThinkPad T14
AMD Gen 5. For more than a minute it was basically *blocked*! I had to wait
easily more than 30 seconds for Ctrl-Alt-F1 to actually do anything. And it
went a two step process. First completely black screen and only then TTY 1
text appeared. But then I could log in just like normal.

My idea about this is as follows, but I did not do any verification so far
as I was completely surprised at that level of excessive memory usage
over the 9,3 GiB the application estimated. 9,3 GiB of RAM would have
been absolutely no issue.

Krita generated a lot, a huge lot of system calls… and these piled up
while the kernel went into "huh, what is that?" mode. Thus my idea is
that at one point the kernel had stalls to process the amount of
system calls. You can easily see something like this with I/O related
stress testing with buffered writes. First it goes tons of context switches
and system calls and then it finds: "Oh shit, I actually really have to do
some work." to write all those buffered write requests out.

Thus you can have insanely fast CPU, you can have PCIexpress 4 based
NVME flash and still with such an easy test that did not even exceed 16
bit limit for pixel coordinates you can make a good part of a desktop
environment crash and before that have the desktop not respond to
user input for a minute for more.

And in parts this is related to using C++. This language has not really
safety constraints that Rust for example has. There can easily be a lot
of pointer related errors.


That all written, first I also wanted to mention that AFAIK Mac OS X uses
Display Postscript everywhere and thus uses coordinates that do not have
to do anything with the hardware display resolution. Thus they need no
crazy even fractional scaling stuff. I may have other disadvantages like
blurry display or what do I know, but I really found this to be an
interesting approach.


I had planned this mail to be much shorter, but then that simple test I
did had this disastrous result.

Now all you "I do not use complex bloated desktop environment" users can
make a fair point :). However I do not yet know how GIMP would have fared.
GIMP also links to desktop environment related library. From the GNOME
world. Is there even a good pixel painting / image manipulation app outside
of desktop environment library sets? Well ImageMagick… and I bet it could
do 50000x50000 pixels. And then I found there is GrafX2 a DeluxePaint /
Brilliance Amiga pixel paint program inspired paint program. However as
GrafX2 is especially meant for making pixel graphics with limited color set
and so on for retro computer based software, I am not sure they'd even
allow 50000x50000 or more pixels.

I will do one last test, after sending this mail. KMail dead letter
recovery worked for the last crash… however I'd rather not risk it.

I will tell Krita to open up a 100000x100 pixel image… that way X
coordinates would exceed 16 bit, while memory usage could still
be low enough.

Best,
--
Martin