Kit process consumes huge amounts of CPU when just clicking in a chart in a spreadsheet

[tml1024]

Start a "make run". Connect to it with a browser in a mobile device (I have seen this on iPad, don't know about others), opening some trivial spreadsheet document with a chart. Tap around in the document, tapping on the chart and tapping on cells. Very soon you will notice that the kit process on the server runs at 100% CPU. If you connect to the browser debug thing from Safari on your Mac, you will see that the client keeps sending apparently identical resizewindow messages and the server keeps responding with corresponding window: messages. Apparently for the sidebar describing the chart?

[tml1024]

Last week I tried bisecting online:co-6-4, didn't find anything sensible. Now bisecting core:cp-6.4.

[tml1024]

Seems that 09afa34955d76419ebe8f4d15780d801f95256ca is the problematic commit. Ping @eszkadev .

[tml1024]

I added some debug output to ScInputWindow::setPosSizePixel():

SAL_DEBUG("Old: " << GetSizePixel().toString() << " at " << GetPosPixel().toString() << " new: " << nWidth << "x" << nHeight << "@" << (nX>=0?"+":"") << nX << (nY>=0?"+":"") << nY);

and indeed it seems that even if the size and position does not change it still does whatever it is doing:

debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0
debug:1872746:1872744: Old: 648, 25 at 0, 0 new: 648x25@+0+0

Will attempt some trivial (?) fix.

[tml1024]

Suggested fix in https://gerrit.libreoffice.org/c/core/+/114056

[mmeeks]

Ooh - sounds really good performance wise =) just merged it. Thanks !