#309 Visual artifacts in Tktable cells with MacOSX Cocoa tk

Using wish8.6 on MacOSX 10.6 (cocoa build; eg. ActiveTcl8.6.0.0b3)

When entering text into tktable cells that are longer than the displayed space
the text is not correct clipped.

Steps to reproduce this bug:
1. start wish8.6
2. source the attached file
3. resize the one or more rows/columns with the mouse

Using the same script with a carbon based wish8.6 (e.g ActiveState 8.6b2) does not
exhibit this behaviour.

[Anonymous]

Demonstration for bug

[Jeffrey Hobbs]

Something about the cocoa text drawing is defying the general clipping routines. If you use -drawmode slow, that is a work-around for now.

[Christopher Chavez]

This issue seems to still be present under Tk 8.6.9.1 (encountered by a user of Tcl::pTk::TableMatrix: https://rt.cpan.org/Ticket/Display.html?id=129543)

Any updates on this? Is this an upstream Tk issue (was a ticket ever opened)? (EDIT: see below; also added screenshot for reference)

[Christopher Chavez]

I have investigated this issue further and filed a Tk bug: https://core.tcl-lang.org/tk/info/685ac3072790118c

The problem is that, on Aqua, any cells with overflowing text will have their text erroneously appear behind the text of every later cell (i.e. a cell in a later column in the same row, or a cell in a later row) with overflowing text (unless -drawmode slow is used). The problem is more clearly seen by overflowing a cell with whitespace or non-overlapping text:

Examining the drawing code in TableDisplay() (tkTable.c), the clipWind pixmap is used when cells have overflowing text: the background and contents already drawn to the cell are copied into clipWind using XCopyArea() the text is then drawn into clipWind and then only the text-containing portion of the cell is copied from clipWind into window using XCopyArea(). The assumption is that existing contents of clipWind are overwritten by the first XCopyArea() for each cell that uses it, but this fails on Aqua, except for -drawmode slow, where window is a pixmap rather than the actual window (the pixmap gets copied to the actual window with XCopyArea() after the entire table is drawn into it).

So this would indicate XCopyArea() is broken on Aqua, at least when the source is not a pixmap, which seems to likely be the case. When the source of an XCopyArea() operation is an actual window rather than a pixmap, it relies on a known-broken function TkMacOSXBitmapRepFromDrawableRect(), which as I understand it, is broken due to the limitation of there being no apparent way to read from a Mac window's "backing store" and get a bitmap or other representation of what has already been drawn so far; maybe the issue is unfixable without drastic changes to Tk.

Some workarounds seem possible from Tktable. It could always use an approach similar to -drawmode slow on Aqua (I'm not sure it's even perceptibly "slow" compared to the other drawing modes on Aqua). Another would be to recreate clipWind for each cell that uses it (this might be the easiest change, since it only involves moving 2 statements). Another is to avoid using XCopyArea() with window as the source, by redrawing into clipWind what is currently being copied into it, draw the text into clipWind, and then only use XCopyArea() to copy the result from clipWind into window (I have not had success with this approach; maybe there is a problem in XCopyArea() even when the source is a pixmap). But I have not completely verified if any of these workarounds truly work, e.g. when using embedded windows.

[Christopher Chavez]

Someone who reported this same issue on comp.lang.tcl (groups.google.com) notices that the -drawmode slow workaround causes fuzzy text when using a Retina display.

Normal cells (not overflowing with text):

Fuzzy cells when using -drawmode slow:

I believe this is because -drawmode slow causes the entire table to be drawn into a pixmap, but text and other content drawn into pixamps is being done at non-Retina (1x) scale, and so when the pixmap is drawn to the screen, it is magnified 200% and antialiased, resulting in fuzzy text. I have opened another Tk ticket for this: https://core.tcl-lang.org/tk/info/e2e9ce70b2

Resolving this might mean that either Tk should make drawing into pixmaps "Retina-aware" (which I suspect there are issues with doing so), or Tktable should not draw into pixmaps (maybe there are issues with doing this as well).

[Christopher Chavez]

I am now prompted to believe there were two separate issues: the one originally reported here, which may have been resolved by Tk at some point; and a new one which I believe was introduced in Tk Aqua 8.6.9. I likely unintentionally hijacked this ticket, as both issues have slightly similar descriptions, same steps for reproducing, and same -drawmode slow workaround.

The new issue will be resolved by Tk Aqua 8.6.11, which now has a working XSetClipRectangles() implementation: https://core.tcl-lang.org/tk/info/b505e5f6a9. But in order to take advantage of it, Tktable must be recompiled with a tiny change (undefine NO_XSETCLIP in tkTable.c; I am attaching a more complete patch provided to me by Marc Culler, a Tk Aqua developer). Once this is done, -drawmode slow should no longer be used in order to avoid the fuzzy text observed on Retina displays.