Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

tablelist and MouseWheel binding on x11

65 views
Skip to first unread message

Nicolas

unread,
Mar 28, 2019, 8:11:03 AM3/28/19
to
Hi Csaba,
using tablelist 6.4, I'm facing a strange issue with <MouseWheel> binding (or <B4> and <B5> as it's x11)

when I'm using two fingers to scroll the tablelist, when it reach the top or the bottom, if I continue scrolling my app is unresponsive for a while, like if binding was triggered again and again...

the bigger the tablelist is, the longer it's unresponsive.

is it something you can confirm?
best regards,
nicolas

nemethi

unread,
Mar 28, 2019, 12:19:25 PM3/28/19
to
Am 28.03.19 um 13:11 schrieb Nicolas:
I am not able to confirm the problem. The binding for <Button-4>
invokes yview scroll -5 units, and the binding for <Button-5> invokes
yview scroll 5 units, regardless of whether the event was triggered by
the mouse wheel or by two-finger scrolling (the binding scripts have no
way to know this).

Just for curiosity: Do you see the issue also when using the mouse
wheel, or only in case of the two-finger scrolling?.

--
Csaba Nemethi http://www.nemethi.de mailto:csaba....@t-online.de

Nicolas

unread,
Mar 28, 2019, 12:36:08 PM3/28/19
to
Hi Csaba,
yes, with the mouse the same behavior occurs...
as yview scroll 5 units is triggered in a binding, I'm wondering if a break would be needed.
I'll test stuff this way tomorrow

thank you for your prompt answer!
best regards,
Nicolas

Nicolas

unread,
Mar 29, 2019, 12:04:16 AM3/29/19
to
so, my issue was not the <MouseWheel> itself... this works as expected
but later on the yview scroll unit call and more precisely in proc tablelist::yviewSubCmd {win argList}

changing updateColors to updateColorsWhenIdle improve the scroll (being more smooth)
I still have lag because of redisplayVisibleItems...
if I remove this call, my tablelist is perfectly smooth when scrolling :)

in case on <Button-4>, <Button-5> or <MouseWheel> binding over the body of the tablelist, does all following calls are necessary?
adjustElidedText $win
redisplayVisibleItems $win
updateColors $win
adjustSepsWhenIdle $win

best regards,
nicolas

nemethi

unread,
Mar 29, 2019, 8:48:49 AM3/29/19
to
Am 29.03.19 um 05:04 schrieb Nicolas:
Those procedure invocations update the view and therefore they are
necessary.

Replacing updateColors with updateColorsWhenIdle can have the negative
effect that the delay with which the color updates within the changed
view are performed leads to some optical artifacts, especially in the
presence of embedded images or windows.

Removing the redisplayVisibleItems invocation is no good idea because
this procedure is responsible for updating the texts within the changed
view. However, you can improve the scrolling performance by setting the
-displayondemand option to false (please a look at the description of
this option in the reference manual).

Nicolas

unread,
Mar 29, 2019, 9:41:21 AM3/29/19
to
thank you for your answer,
I've set -displayondemand 0 but I'm still facing huge lag, especially when the scrollbar is at the top or at the bottom.

best regards,
nicolas


Brad Lanam

unread,
Mar 29, 2019, 3:14:22 PM3/29/19
to
On Friday, March 29, 2019 at 6:41:21 AM UTC-7, Nicolas wrote:
> Le vendredi 29 mars 2019 13:48:49 UTC+1, nemethi a écrit :
> > Am 29.03.19 um 05:04 schrieb Nicolas:
> > > Le jeudi 28 mars 2019 17:36:08 UTC+1, Nicolas a écrit :
> > > [...]
> > > changing updateColors to updateColorsWhenIdle improve the scroll (being more smooth)
> > > I still have lag because of redisplayVisibleItems...
> > > if I remove this call, my tablelist is perfectly smooth when scrolling :)
> > >
> > > in case on <Button-4>, <Button-5> or <MouseWheel> binding over the body of the tablelist, does all following calls are necessary?
> > > adjustElidedText $win
> > > redisplayVisibleItems $win
> > > updateColors $win
> > > adjustSepsWhenIdle $win
> > >
> > > best regards,
> > > nicolas
> > >
> >
> > Those procedure invocations update the view and therefore they are
> > necessary.
> >
> > Replacing updateColors with updateColorsWhenIdle can have the negative
> > effect that the delay with which the color updates within the changed
> > view are performed leads to some optical artifacts, especially in the
> > presence of embedded images or windows.
> >
> > Removing the redisplayVisibleItems invocation is no good idea because
> > this procedure is responsible for updating the texts within the changed
> > view. However, you can improve the scrolling performance by setting the
> > -displayondemand option to false (please a look at the description of
> > this option in the reference manual).
> >
> > --
> > Csaba Nemethi http://www.nemethi.de
>
> thank you for your answer,
> I've set -displayondemand 0 but I'm still facing huge lag, especially when the scrollbar is at the top or at the bottom.
>
> best regards,
> nicolas

I don't use tablelist, but I found that this sort of code
was necessary for 'moveto' (i.e. grab the scrollbar handle and move it)
to prevent lagging when updating the display while scrolling:

if { $cmd eq "moveto" } {
if { $sdvars(scroll.afterid) ne {} } {
after cancel $sdvars(scroll.afterid)
}
set sdvars(scroll.afterid) [after 1 [list [self] sd_scroll]]
}
# where sd_scroll is the actual display update procedure...

A slight delay to wait for another 'moveto' command and if one is received,
restart the after command. A delay of 1 is a bit small, I could raise
that to 5 probably.

The same sort of thing could be done for the other scroll operations
(in which case, I would use a delay of 1).

My application's display update is not as heavy as tablelist, so I can't
really run a meaningful test. The scrollwheel works fine with or without
the delay in my particular situation.

nemethi

unread,
Mar 29, 2019, 5:28:43 PM3/29/19
to
Am 29.03.19 um 20:14 schrieb Brad Lanam:
The tablelist implementation already contains a similar code for
handling the yview moveto command.

--
Csaba Nemethi http://www.nemethi.de mailto:csaba....@t-online.de

Nicolas

unread,
Mar 30, 2019, 1:45:45 AM3/30/19
to
here's my tablelist code:
https://pastebin.com/xu1QvRDx
nothing fancy nor special....

when I click on the scrollbar with the trackpad and scrolling, no problem.
when I make a big movement with two fingers, the scrollbar reach the top (or the bottom depending the way) and <B-4>or <B-5> is trigered again and again and thus block my app.

it's the yview scroll xx units that's fired, not the yview moveto...

++

nemethi

unread,
Mar 30, 2019, 7:20:46 AM3/30/19
to
Am 30.03.19 um 06:45 schrieb Nicolas:
Of course it is not yview moveto (I just wanted to respond to Brad's
posting).

How many rows and columns does your tablelist widget have? Does it also
contain embedded images or windows? If yes, in how many columns? I am
asking this because I am still not able to reproduce your problem.

Nicolas

unread,
Mar 30, 2019, 7:34:20 AM3/30/19
to
here's a paste of my Tablelist:
https://paste.pics/175a55d6b3342db3b7c296d6a3a9208c

this tablelist count 52 rows,
step text colums are ttk::entry

thank you for investigating on this.
++

Nicolas

unread,
Apr 1, 2019, 1:23:20 AM4/1/19
to
just for letting Brad knows...
Csaba sent me code with an optimized version of yview scroll xx units and now it works great and smooth!

thank you guys for taking time to investigate on this.

++
Nicolas
0 new messages