In my usage, blitting can often be over 100 ms, which is a long time to hold the GIL... especially while not using the Python C API. I verified the safety of releasing the GIL back in2ad422a but for some reason I took it back out when thread-based parallelism didn't work out. (#18565)

_tkagg.blit has been backed byTk_PhotoPutBlock_NoComposite since#6442. This interface is deprecated, and on Tk 8.5 and laterTk_PhotoPutBlock gives the option to composite or not as a function argument, avoiding the need for an extra blanking step and permitting afast path when the data are properly aligned, which seems to be the case on TkAgg. My profiling shows that the time spent specifically in_tkagg.blit drops by a factor of 2 to 10 (!?) in the naive use case of callingfig.canvas.draw(). However,FigureCanvasAgg.draw is the main time sink in either case, so the FPS gains are limited, and for large canvases blitting still takes enough time to make dropping the GIL worthwhile. Nevertheless, I get a practical responsivity boost in a downstream application (100 ms -> 10 ms blit latency) so I think it is worth sharing.

If anyone can tell me why this speedup is only visible whenFigure.get_frameon()==True, I will sleep much better at night. It would seem to have to do with the abundance or paucity of transparent pixels in thePhotoImage, but the Tksource doesn't inspect that directly. Could it boil down to CPU branch prediction?

This change is backwards-incompatible with Tk < 8.5. I don't think that affects Python 3 or Matplotlib 3 users, but I would like confirmation. Also I would like someone to check if this change is problematic in the TkCairo backend

PR Checklist

~~Has pytest style unit tests~~ (andpytest passes).
IsFlake 8 compliant (runflake8 on changed files to check).
~~[ ] New features are documented, with examples if plot related.~~
~~[x] Documentation is sphinx and numpydoc compliant (the docs shouldbuild without error).~~
~~[ ] Conforms to Matplotlib style conventions (installflake8-docstrings and runflake8 --docstring-convention=all).~~
~~[ ] New features have an entry indoc/users/next_whats_new/ (follow instructions in README.rst there).~~
API changes documented indoc/api/next_api_changes/ (follow instructions in README.rst there).

richardsheridan added6 commits

August 15, 2021 07:48

find and load Tk_PhotoPutBlock

1fbe7fe

Substitute TkPhotoPutBlock

8f4ed5d

Also release GILCurrently, drawing an equivalence between blank and TK_PHOTO_COMPOSITE_SET which may not be entirely accurate

Delete old, deprecated api

422b8d7

more descriptive names for composition rule

2efc4f5

fix test

5709e7b

flake8

dd447a0

richardsheridan added the GUI: tk label

Aug 15, 2021

propagate memory errors from Tcl

9eb95f5

anntzer reviewed

Aug 16, 2021

View reviewed changes

src/_tkagg.cpp OutdatedShow resolvedHide resolved

Copy link

Contributor

anntzer commentedAug 16, 2021

This change is backwards-incompatible with Tk < 8.5.

Based ontcltk/tk@8abf694 this seems backcompatible to as far back as tk 8.4.0 (2002)? Or did I miss something? It's not clear why this was changed in#6442.

I don't think that affects Python 3 or Matplotlib 3 users, but I would like confirmation.

8.4.0 seems certainly old enough that we can require it, although a doc note may be good (I can't find any mention in the cpython docs stating that it cannot be built against tk 8.3, although that may be a bit academic).

Also I would like someone to check if this change is problematic in the TkCairo backend

At least you'll need to simimarly adjust the call to_backend_tk.blit in backend_tkcairo.py.

richardsheridan added2 commits

August 16, 2021 06:34

remove unneeded typedef

800a8ee

formatting

5376ab4

Copy link

ContributorAuthor

richardsheridan commentedAug 16, 2021

Based ontcltk/tk@8abf694 this seems backcompatible to as far back as tk 8.4.0 (2002)? Or did I miss something? It's not clear why this was changed in#6442.

I based 8.5 on a fuzzy reading of the docs, if it's there in 8.4, then it's even less of an issue

8.4.0 seems certainly old enough that we can require it, although a doc note may be good (I can't find any mention in the cpython docs stating that it cannot be built against tk 8.3, although that may be a bit academic).

If you can point me to roughly the right file in the docs, I'm happy to make a change. Probably a.. warning:: or.. note::, right?

At least you'll need to simimarly adjust the call to_backend_tk.blit in backend_tkcairo.py.

The call signature of_backend_tk.blit hasn't changed, only_tkagg.blit. Maybe it is worth giving them different names? It would make debugging/profiling a little less confusing too.

Copy link

Contributor

anntzer commentedAug 16, 2021•
edited
Loading

If you can point me to roughly the right file in the docs, I'm happy to make a change. Probably a .. warning:: or .. note::, right?

There's a list in doc/devel/dependencies.rst; an api_changes entry seems safe too.

Maybe it is worth giving them different names?

Yes, that's a bit confusing. It's all private anyways, so they can be changed at will.

Looks like tkcairo works fine with this (well, possibly modulo some preexisting compositing issues, but they are not introduced by the changes here).

richardsheridan added2 commits

August 16, 2021 09:03

Update dependencies.rst

bb611bf

Create 20840-RJS.rst

ef27e2b

richardsheridan added this to thev3.5.0 milestone

Aug 16, 2021

Copy link

Contributor

anntzer commentedAug 16, 2021•
edited
Loading

If anyone can tell me why this speedup is only visible when Figure.get_frameon()==True, I will sleep much better at night. It would seem to have to do with the abundance or paucity of transparent pixels in the PhotoImage, but the Tk source doesn't inspect that directly. Could it boil down to CPU branch prediction?

I don't really know, but it does seem that successfully always predictingalpha == 255 athttps://github.com/tcltk/tk/blob/5745147320011c82db86941f349d25a690cf914b/generic/tkImgPhoto.c#L3440 could indeed help.