开发者

Size limitations of Tkinter grid manager

开发者 https://www.devze.com 2023-03-14 17:15 出处:网络
I\'m writing a Python application to parse a list of binary files, aggregate statistics on the data in them, and output results. I can easily output these results as a .tsv file, but this program is b

I'm writing a Python application to parse a list of binary files, aggregate statistics on the data in them, and output results. I can easily output these results as a .tsv file, but this program is being written for the convenience of my coworkers, so I'm开发者_开发技巧 trying to have it display the results in a new window to sometimes prevent having to open the file in Excel. Right now I'm basically embedding a Tkinter frame in a scrolled canvas and gridding smaller frames containing labels of the data into the frame. (The smaller frames seem to be necessary to get all the borders to line up with the gridlines; otherwise they are shrinkwrapped to fit the labels)

This approach works with upwards of a hundred columns and maybe ten rows. But when I start increasing the number of rows to the hundreds, I start encountering odd problems. The program might become unresponsive, the new window might not display, and all the labels, rather than being drawn in the grid, are all placed in the top left corner of my screen. Since this appears to be a scale-related problem, I'm wondering if I'm simply overwhelming the grid manager with tens of thousands of elements to place. So I have two questions: 1) Could I be running into such limitations, or is the problem elsewhere, and 2) Is there a better way to implement an Excel-like table display in Tkinter that steers clear of these problems?


I wrote a test program to display the data two ways, once using a frame and grid and once drawing text directly on the canvas.

Using the frame+grid technique, the performance of 100 rows times 10 columns was quite acceptable. When I bumped that up to 200 rows the performance was more than 2x worse, and by the time I got to 300 rows, performance was unusable. And by that I mean, it took dozens of seconds for the initial display. Once the window appeared, however, the performance was acceptable.

Drawing text items directly on the canvas, performance was considerably better. I could display 300 rows by 10 columns and the initial display was almost instantaneous. Performance was still acceptable when I had 1000 rows with 100 columns, taking maybe 2-3 seconds to start up.

So, for a large number of cells you're better off drawing them directly on the canvas. This means you'll need to calculate the height of a row yourself, and also do a little math for the columns -- either use fixed width columns or keep track of the widest and then adjust the coordinates accordingly.


The grid geometry manager runs into problems as things get larger; it's not designed for dealing with very large numbers of subwindows (i.e., anything where you'd want to scale beyond what you can comfortably have without scrolling). Instead, you're looking for TkTable. That can scale up to handling very large tabular data.

0

精彩评论

暂无评论...
验证码 换一张
取 消