I've been experimenting with placing widgets inside a canvas. When I tried to test it's performance on lots of widgets (in a column) I am seeing the last few widgets not being displayed when the code does

[winfo reqheight $content]

where content is a frame and the value returned is over 32768 (actually starts failing just shy of that value).

This naturally leads me to suspect there's a 16 bit issue here.

I'm testing on windows 10, with 8.6 and 9.0 and get the same results.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 14.04.2025 um 05:44 schrieb et99:

I've been experimenting with placing widgets inside a canvas. When I
tried to test it's performance on lots of widgets (in a column) I am
seeing the last few widgets not being displayed when the code does

[winfo reqheight $content]

where content is a frame and the value returned is over 32768 (actually starts failing just shy of that value).

This naturally leads me to suspect there's a 16 bit issue here.

I'm testing on windows 10, with 8.6 and 9.0 and get the same results.

Unfortunately yes.

This is very annoying, specially in a virtual canvas, where scrolling is
used to display only a part.

And the biggest point is, that if you exceed the size, there is no
error, but display disruption, as widgets will be placed at negative coordinates etc.

The last experience is on Windows...

You have hit another swamp to clean-up...

Sorry,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 14.04.2025 um 08:33 schrieb Harald Oehlmann:

Am 14.04.2025 um 05:44 schrieb et99:

I've been experimenting with placing widgets inside a canvas. When I
tried to test it's performance on lots of widgets (in a column) I am
seeing the last few widgets not being displayed when the code does

[winfo reqheight $content]

where content is a frame and the value returned is over 32768
(actually starts failing just shy of that value).

This naturally leads me to suspect there's a 16 bit issue here.

I'm testing on windows 10, with 8.6 and 9.0 and get the same results.

Unfortunately yes.

This is very annoying, specially in a virtual canvas, where scrolling is
used to display only a part.

And the biggest point is, that if you exceed the size, there is no
error, but display disruption, as widgets will be placed at negative coordinates etc.

The last experience is on Windows...

You have hit another swamp to clean-up...

Sorry,
Harald

Tonts of Tk tickets on that:

https://core.tcl-lang.org/tk/tktview/3307625fff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ah, I thought so Harald. You have read my mind, as that's exactly what I was trying to do.

I was testing some wiki code, at https://wiki.tcl-lang.org/page/A+scrolled+frame by Paul Walton (his sframe.tcl at the bottom) which worked quite well for a spreadsheet like tool to display some csv files with a matrix of entry widgets.

At least until I tried it on some large sample csv files I found at a csv site. It dies on the 1000 row files.

And thanks for the link to the ticket.

I begin to see why what to me has always seemed to be a missing piece of Tk, a -scrollable option for frames and toplevels.

I wonder how bwidgets and scrollutils handle large amounts of data. I have tried both but never with large amounts of data. It seems the answer is NOT to try to embed many thousands of entry widgets in a canvas.

Eric


On 4/13/2025 11:46 PM, Harald Oehlmann wrote:

Am 14.04.2025 um 08:33 schrieb Harald Oehlmann:

Am 14.04.2025 um 05:44 schrieb et99:

I've been experimenting with placing widgets inside a canvas. When I tried to test it's performance on lots of widgets (in a column) I am seeing the last few widgets not being displayed when the code does

[winfo reqheight $content]

where content is a frame and the value returned is over 32768 (actually starts failing just shy of that value).

This naturally leads me to suspect there's a 16 bit issue here.

I'm testing on windows 10, with 8.6 and 9.0 and get the same results.

Unfortunately yes.

This is very annoying, specially in a virtual canvas, where scrolling is used to display only a part.

And the biggest point is, that if you exceed the size, there is no error, but display disruption, as widgets will be placed at negative coordinates etc.

The last experience is on Windows...

You have hit another swamp to clean-up...

Sorry,
Harald

Tonts of Tk tickets on that:

https://core.tcl-lang.org/tk/tktview/3307625fff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eric,
all tools by Csaba do not show this issue.
You may try scrollutil or tablelist.
Both perform great for large data.

Of cause, pure C widgets are faster: tktable,...
For csv, you have Ashoks widget.

All those widgets paint only the visible part and not (yet) the invisible. tablelist even has a callback to paint on demand.
Paul has shown this with a table a 20000 rows containing big images and
it was fluent.

BWidget suffers of the limit.
BWidget is anyway a hack nowdays, as ttk support is poor.
20 years ago, it was a milestone..

Take care,
Harald

Am 14.04.2025 um 11:45 schrieb et99:

Ah, I thought so Harald. You have read my mind, as that's exactly what I
was trying to do.

I was testing some wiki code, at https://wiki.tcl-lang.org/page/ A+scrolled+frame by Paul Walton (his sframe.tcl at the bottom) which
worked quite well for a spreadsheet like tool to display some csv files
with a matrix of entry widgets.

At least until I tried it on some large sample csv files I found at a
csv site. It dies on the 1000 row files.

And thanks for the link to the ticket.

I begin to see why what to me has always seemed to be a missing piece of
Tk, a -scrollable option for frames and toplevels.

I wonder how bwidgets and scrollutils handle large amounts of data. I
have tried both but never with large amounts of data. It seems the
answer is NOT to try to embed many thousands of entry widgets in a canvas.

Eric

On 4/13/2025 11:46 PM, Harald Oehlmann wrote:

Am 14.04.2025 um 08:33 schrieb Harald Oehlmann:

Am 14.04.2025 um 05:44 schrieb et99:

I've been experimenting with placing widgets inside a canvas. When I
tried to test it's performance on lots of widgets (in a column) I am
seeing the last few widgets not being displayed when the code does

[winfo reqheight $content]

where content is a frame and the value returned is over 32768
(actually starts failing just shy of that value).

This naturally leads me to suspect there's a 16 bit issue here.

I'm testing on windows 10, with 8.6 and 9.0 and get the same results.

Unfortunately yes.

This is very annoying, specially in a virtual canvas, where scrolling
is used to display only a part.

And the biggest point is, that if you exceed the size, there is no
error, but display disruption, as widgets will be placed at negative
coordinates etc.

The last experience is on Windows...

You have hit another swamp to clean-up...

Sorry,
Harald

Tonts of Tk tickets on that:

https://core.tcl-lang.org/tk/tktview/3307625fff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

et99 <et99@rocketship1.me> posted:

Virtuallist should be a good candidate with 2**30 elements displayed as a breeze

https://wiki.tcl-lang.org/page/Virtuallist

It is based on a canvas and display only a part of the elements according to request.

the Hugelist is maybe better formatted to what you need ?

Olivier.

I've been experimenting with placing widgets inside a canvas. When I tried to test it's performance on lots of widgets (in a column) I am seeing the last few widgets not being displayed when the code does

[winfo reqheight $content]

where content is a frame and the value returned is over 32768 (actually starts failing just shy of that value).

This naturally leads me to suspect there's a 16 bit issue here.

I'm testing on windows 10, with 8.6 and 9.0 and get the same results.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 13 Apr 2025 20:44:50 -0700
et99 <et99@rocketship1.me> wrote:

I've been experimenting with placing widgets inside a canvas. When I tried to test it's performance on lots of widgets (in a column) I am seeing the last few widgets not being displayed when the code does

[winfo reqheight $content]

where content is a frame and the value returned is over 32768 (actually starts failing just shy of that value).

This is X11 heritage. On X coordinates are limited to 32767.

$ wish9.1
% frame .f -width 32768
.f
% pack .f
% X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 137
Current serial number in output stream: 144

This limitation is hardcoded in Tk API as well. For example, the function

Tk_CanvasDrawableCoords(
Tk_Canvas canvas,
double x,
double y,
short *drawableXPtr,
short *drawableYPtr);

can't return coordinates bigger than 32767 for the canvas drawable.

--
Emiliano

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/14/2025 3:18 AM, Harald Oehlmann wrote:

Eric,
all tools by Csaba do not show this issue.
You may try scrollutil or tablelist.
Both perform great for large data.

Of cause, pure C widgets are faster: tktable,...
For csv, you have Ashoks widget.

All those widgets paint only the visible part and not (yet) the invisible. tablelist even has a callback to paint on demand.
Paul has shown this with a table a 20000 rows containing big images and it was fluent.

BWidget suffers of the limit.
BWidget is anyway a hack nowdays, as ttk support is poor.
20 years ago, it was a milestone..

Take care,
Harald

Actually, I am finding pretty much the same behavior in scrollutil's. I took the example from the demo folder,

SuScrollableFrmDemo1.tcl

and modified it to repeat the cities until I got to 21 times bigger

set countryList0 $countryList
for {set m 0} {$m < 21} {incr m} {
set countryList "$countryList $countryList0"
}

Here's the top part of the widget tree that get's created:



. - test
| .f - TFrame
| | .f.sa - Scrollarea
| | | .f.sa.hsb - TScrollbar
| | | | .f.sa.hsb.f - TFrame
| | | .f.sa.vsb - TScrollbar
| | | | .f.sa.vsb.f - TFrame
| | | .f.sa.sf - Scrollableframe
| | | | .f.sa.sf.mf - ScrollableframeMf
| | | | | .f.sa.sf.mf.cf - ScrollableframeCf
| | | | | | .f.sa.sf.mf.cf.l0 - TLabel
| | | | | | .f.sa.sf.mf.cf.cb0 - TCombobox
| | | | | | .f.sa.sf.mf.cf.b0 - TButton Resolve
...


This modified code results in 1012 rows created but only 992 show up and for the ScrollableframeCf: reqheight = 33396

The above is displaying the [winfo class ...] and I'm not sure what that widget really is, or if it's just a canvas in hiding. The frame above it, the ScrollableframeCf displays as 333 regardless of how many widgets are placed in the frame.

So even if I used the scrollutil package, I would still have the same limitation if I tried to embed that many rows of widgets in a scrollable frame.

I see the ticket for this is rather old, and so it does not appear anything is going to be done for this in the near future.

Bwidgets is out of the question, since I'm also trying to avoid using any packages that are not in Ashok's tclkits/gui/twapi that I use when I distribute any tcl code for others to use on windows.

Eric

Am 14.04.2025 um 11:45 schrieb et99:

Ah, I thought so Harald. You have read my mind, as that's exactly what I was trying to do.

I was testing some wiki code, at https://wiki.tcl-lang.org/page/ A+scrolled+frame by Paul Walton (his sframe.tcl at the bottom) which worked quite well for a spreadsheet like tool to display some csv files with a matrix of entry widgets.

At least until I tried it on some large sample csv files I found at a csv site. It dies on the 1000 row files.

And thanks for the link to the ticket.

I begin to see why what to me has always seemed to be a missing piece of Tk, a -scrollable option for frames and toplevels.

I wonder how bwidgets and scrollutils handle large amounts of data. I have tried both but never with large amounts of data. It seems the answer is NOT to try to embed many thousands of entry widgets in a canvas.

Eric


On 4/13/2025 11:46 PM, Harald Oehlmann wrote:

Am 14.04.2025 um 08:33 schrieb Harald Oehlmann:

Am 14.04.2025 um 05:44 schrieb et99:

I've been experimenting with placing widgets inside a canvas. When I tried to test it's performance on lots of widgets (in a column) I am seeing the last few widgets not being displayed when the code does

[winfo reqheight $content]

where content is a frame and the value returned is over 32768 (actually starts failing just shy of that value).

This naturally leads me to suspect there's a 16 bit issue here.

I'm testing on windows 10, with 8.6 and 9.0 and get the same results. >>>>>

Unfortunately yes.

This is very annoying, specially in a virtual canvas, where scrolling is used to display only a part.

And the biggest point is, that if you exceed the size, there is no error, but display disruption, as widgets will be placed at negative coordinates etc.

The last experience is on Windows...

You have hit another swamp to clean-up...

Sorry,
Harald

Tonts of Tk tickets on that:

https://core.tcl-lang.org/tk/tktview/3307625fff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks for the suggestions. The purpose of my "little" project was to demonstrate that TCL/Tk was the best tool in a particular environment. The user needed a tool to do a csv column cut operation on a csv formatted text file, as an extension to a
commercial text editor he was using.

My workaround is to simply limit the rows shown to a max of 500. The really cool stuff is to display the csv's first row as checkboxes so the user can select which columns to cut on the output. That's better than the user having to construct a python
csvkit/csvcut command line with the column labels or numbers by hand.

The actual display of the data was just some added sugar to "show off" tcl/tk. Had I also been able to just do [frame .container -scrollable both] I would have been doing victory laps :)

Eric






On 4/14/2025 5:54 AM, Olivier wrote:

et99 <et99@rocketship1.me> posted:

Virtuallist should be a good candidate with 2**30 elements displayed as a breeze

https://wiki.tcl-lang.org/page/Virtuallist

It is based on a canvas and display only a part of the elements according to request.

the Hugelist is maybe better formatted to what you need ?

Olivier.

I've been experimenting with placing widgets inside a canvas. When I tried to test it's performance on lots of widgets (in a column) I am seeing the last few widgets not being displayed when the code does

[winfo reqheight $content]

where content is a frame and the value returned is over 32768 (actually starts failing just shy of that value).

This naturally leads me to suspect there's a 16 bit issue here.

I'm testing on windows 10, with 8.6 and 9.0 and get the same results.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 15.04.25 um 03:36 schrieb et99:

Thanks for the suggestions. The purpose of my "little" project was to demonstrate that TCL/Tk was the best tool in a particular environment.
The user needed a tool to do a csv column cut operation on a csv
formatted text file, as an extension to a commercial text editor he was using.

If I had to do it, I'd use tablelist. I've yet to find a use-case where
you can't simply set an option to it to do what you want.

Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/15/2025 11:52 PM, Christian Gollwitzer wrote:

Am 15.04.25 um 03:36 schrieb et99:

Thanks for the suggestions. The purpose of my "little" project was to demonstrate that TCL/Tk was the best tool in a particular environment. The user needed a tool to do a csv column cut operation on a csv formatted text file, as an extension to a

commercial text editor he was using.

If I had to do it, I'd use tablelist. I've yet to find a use-case where you can't simply set an option to it to do what you want.

Christian

Thanks for that. I had a look at tablelist.

I was quite impressed that I could change a demo to display over 50,000 lines and it didn't have the problem that examples using canvas had. I looked at the widget tree and found it was using a text widget for the container.

My goal was to demo only using the core set of tk widgets. That's why I didn't want to rely on any packages. I wanted scrollable frames, so I snagged 80 lines of wiki code.

But in the end I was able to create a spreadsheet like layout of modifiable cells, with just two small nested foreach loops of grid'd entry's, plus some csv split and reconstruct functions that I got the google gemini AI bot to write for me.

Since the csv data comes in via stdin, I was able to demo: [split [read -nonewline stdin] \n] which is a nice tcl thing.

Did I succeed? Only time will tell.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)