Caching client rectangle on EditView

[Neil Hodgson]

The right-to-left code currently being worked on appears to need access to the rectangle of the text or, at least, its width. Currently, this is available as Editor::GetClientRectangle and is queried from the system. Its not available to EditView methods unless it is passed in. It is more expensive to make a system call than to access a variable, and Editor receives ChangeSize calls from the platform layer when the window has changed size.

Therefore, I think that the client rectangle should be cached as a field of EditView, set in the ChangeSize method. To preserve current platform code, the existing Editor::GetClientRectangle would stay but a ‘PRectangle rectangleView' would be added to EditView along with GetViewRectangle and SetViewRectangle methods. SetViewRectangle would be called in ChangeSize with the result of GetClientRectangle allowing platform subclasses to override. EditView::GetViewRectangle would replace all calls to GetClientRectangle except for the one in ChangeSize.

There is also a ‘client drawing rectangle’ which is, on most platforms, identical to the client rectangle. On Cocoa, however, extra tiles are drawn (‘prepared’) beyond the area currently visible to allow for high performance scrolling. There doesn’t appear to be a way to receive events when the prepared area changes, so GetClientDrawingRectangle will still need to be called to allow for Cocoa to override.

Neil

[Neil Hodgson]

This change has been committed as
https://sourceforge.net/p/scintilla/code/ci/7402342dc7a36bfb7c2af2296e2bdd81e635d399/

Neil

[Neil Hodgson]

There are problems with this change with Qt 4.8.7 on Fedora Linux 27 with Wayland where there may not be a resizeEvent. The tests scripts in scintilla/test like simpleTests.py don’t show an Event::Resize or a call to resizeEvent at all. On ScintillaEditBase, the QEvents that are logged before failure are 68, 152, 109, and 178 which translate to ChildAdded, unknown, MouseTrackingChange, and ContentsRectChange.

Calling Editor::ChangeSize when ContentsRectChange is received makes everything work with reasonable values but that makes it look like Scintilla’s current resize tracking is incorrect. It is possible that ContentsRectChange should be treated as a resize event - do real resize events only go to top-level windows?

Calling ChangeSize at the end of the ScintillaEditBase constructor also works with sensible values.

Its possible that this version of Qt and platform only send resize events when the window changes size and the initial display is not seen as a resize.

Neil

[Neil Hodgson]

I will have to undo this change set. While it seems to work OK at first on Cocoa, it breaks down when the view is scrolled because Cocoa uses a different co-ordinate system so the client rectangle is relative to the document top, not the window top.

Neil