Re: are canvas coordinates limited to 32k

Liste des GroupesRevenir à cl tcl 
Sujet : Re: are canvas coordinates limited to 32k
De : et99 (at) *nospam* rocketship1.me (et99)
Groupes : comp.lang.tcl
Date : 15. Apr 2025, 01:34:53
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vtk9jd$2fp9c$1@dont-email.me>
References : 1 2 3 4 5
User-Agent : Mozilla Thunderbird
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
>
>
>
 

Date Sujet#  Auteur
14 Apr 25 * are canvas coordinates limited to 32k11et99
14 Apr 25 +* Re: are canvas coordinates limited to 32k5Harald Oehlmann
14 Apr 25 i`* Re: are canvas coordinates limited to 32k4Harald Oehlmann
14 Apr 25 i `* Re: are canvas coordinates limited to 32k3et99
14 Apr 25 i  `* Re: are canvas coordinates limited to 32k2Harald Oehlmann
15 Apr 25 i   `- Re: are canvas coordinates limited to 32k1et99
14 Apr 25 +* Re: are canvas coordinates limited to 32k4Olivier
15 Apr 25 i`* Re: are canvas coordinates limited to 32k3et99
16 Apr 25 i `* Re: are canvas coordinates limited to 32k2Christian Gollwitzer
19 Apr 25 i  `- Re: are canvas coordinates limited to 32k1et99
14 Apr 25 `- Re: are canvas coordinates limited to 32k1Emiliano

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal