You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In ImageView, I have an application where I'm painting a 5-megapixel surface in a loop. It plays more slowly than I'd like under these circumstance. I noticed that if I zoom in on a smaller region---keeping the size of the window constant---that it plays much faster. I therefore assumed that the bottleneck was the fill operation. However, profiling suggests this is not the case, and that Tk.update() is the main bottleneck. For mysterious reasons, the time required for Tk.update() seems to vary with the size of the source that is painted to the canvas, even though I would have guessed that Tk.update would have no way of "knowing" that information because only the canvas should matter.
So, here's a systematic test. The code in this gist tests 3 operations---Cairo.fill, Tk.reveal, and Tk.update---for sources and canvases of different sizes. You can ignore the normalization part, here I'm just showing the raw timings.
If one discards the smallest source, the fill operation very quickly settles into scaling with the source area. This is as I would expect.
reveal seems approximately constant-time
update depends more strongly on the source area than the canvas size, and undergoes a fairly catastrophic loss of performance for the largest source areas.
This last result makes absolutely no sense to me. One point worth noting is that tupdate is always larger than tfill, but that the time difference is not constant (which might be predicted if there were asynchronous operations happening). Does anyone else understand?
The text was updated successfully, but these errors were encountered:
In ImageView, I have an application where I'm painting a 5-megapixel surface in a loop. It plays more slowly than I'd like under these circumstance. I noticed that if I zoom in on a smaller region---keeping the size of the window constant---that it plays much faster. I therefore assumed that the bottleneck was the
fill
operation. However, profiling suggests this is not the case, and thatTk.update()
is the main bottleneck. For mysterious reasons, the time required forTk.update()
seems to vary with the size of the source that is painted to the canvas, even though I would have guessed thatTk.update
would have no way of "knowing" that information because only the canvas should matter.So, here's a systematic test. The code in this gist tests 3 operations---
Cairo.fill
,Tk.reveal
, andTk.update
---for sources and canvases of different sizes. You can ignore the normalization part, here I'm just showing the raw timings.Results:
Interpretation:
fill
operation very quickly settles into scaling with the source area. This is as I would expect.reveal
seems approximately constant-timeupdate
depends more strongly on the source area than the canvas size, and undergoes a fairly catastrophic loss of performance for the largest source areas.This last result makes absolutely no sense to me. One point worth noting is that
tupdate
is always larger thantfill
, but that the time difference is not constant (which might be predicted if there were asynchronous operations happening). Does anyone else understand?The text was updated successfully, but these errors were encountered: