I realized, that the "update" or "update idletasks" command can cause some performance issues when applied in a GUI.

For example: I need to use "update" in order to correctly get values from "winfo reqwidth". This causes a small delay that is perceptible.

The question is: Is there another way to get current values from "winfo reqwidth" without having to use "update"?

Many thanks
Alexandru

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

* Alexandru <alexandru.dadalau@meshparts.de>
| For example: I need to use "update" in order to correctly get values
| from "winfo reqwidth". This causes a small delay that is perceptible.

| The question is: Is there another way to get current values from
| "winfo reqwidth" without having to use "update"?

You could try to bind to the <Configure> event (widget changes size), or
to <Map> (widget gets displayed). With <Configure> you need to wait for
a notification where the size reported is > 1x1, so it might or might
not help, depending on your needs.

HTH
R'

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

On 10/12/2021 11:05, Alexandru wrote:

I realized, that the "update" or "update idletasks" command can cause some performance issues when applied in a GUI.

It matters whether you choose [update idletasks] or [update].

In my experience, a raw [update] is overkill in this case. It may do much more than just induce a
size computation, and therefore it could be a cause of an extra performance penalty.

Erik.

For example: I need to use "update" in order to correctly get values from "winfo reqwidth". This causes a small delay that is perceptible.

The question is: Is there another way to get current values from "winfo reqwidth" without having to use "update"?

Many thanks
Alexandru

--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

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

Erik Leunissen schrieb am Freitag, 10. Dezember 2021 um 13:12:10 UTC+1:

On 10/12/2021 11:05, Alexandru wrote:

I realized, that the "update" or "update idletasks" command can cause some performance issues when applied in a GUI.

It matters whether you choose [update idletasks] or [update].

In my experience, a raw [update] is overkill in this case. It may do much more than just induce a
size computation, and therefore it could be a cause of an extra performance penalty.

Erik.

Yes, I know. In my specific case though, it make no difference.
Maybe it's a Windows thing. I don't know. But here is where the theory differs from the practice.

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

Dear Alexandru,

please find here my 3 cents:

it is normally not the update, but program structure.

On each update, any event driven code may run.
So, if you have io events or after tasks - they may run within the
update and will cause an arbitrary delay.

If Tk has redraws pending, this will happen with the update.
So, here, update can be very slow, but then, the work is done.
Otherwise, the work would be done after your procedure and you would not measure it.

Take care,
Harald

Am 10.12.2021 um 13:27 schrieb Alexandru:

Erik Leunissen schrieb am Freitag, 10. Dezember 2021 um 13:12:10 UTC+1:

On 10/12/2021 11:05, Alexandru wrote:

I realized, that the "update" or "update idletasks" command can cause some performance issues when applied in a GUI.

It matters whether you choose [update idletasks] or [update].

In my experience, a raw [update] is overkill in this case. It may do much more than just induce a
size computation, and therefore it could be a cause of an extra performance penalty.

Erik.

Yes, I know. In my specific case though, it make no difference.
Maybe it's a Windows thing. I don't know. But here is where the theory differs from the practice.

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

On Friday, December 10, 2021 at 2:05:59 AM UTC-8, Alexandru wrote:

I realized, that the "update" or "update idletasks" command can cause some performance issues when applied in a GUI.

For example: I need to use "update" in order to correctly get values from "winfo reqwidth". This causes a small delay that is perceptible.

The question is: Is there another way to get current values from "winfo reqwidth" without having to use "update"?

Many thanks
Alexandru

It has been my experience that the use of [update], in any form, is rarely the correct answer. The only time it is necessary is in a regression test, and even then it is often problematic.

I would first start by rethinking the problem and find a solution that does not require [update]. Ralf's suggestion is one example of a superior solution to using [update] when needing accurate geometry info.

For [update idletasks] I would suggest using [after idle] as a way to generate a one-time pseudo event to trigger the completion of a task after some prior "idle" task that was scheduled. [after idle] can be used within a coroutine to give the
appearance of sequential coding that may be easer to reason about it's correctness. For example:

wm deiconify $w
after idle [info coroutine]
yield
set geom [winfo geom $w]
...
return

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

Ralf Fassel schrieb am Freitag, 10. Dezember 2021 um 12:13:20 UTC+1:

* Alexandru <alexandr...@meshparts.de>
| For example: I need to use "update" in order to correctly get values
| from "winfo reqwidth". This causes a small delay that is perceptible.

| The question is: Is there another way to get current values from
| "winfo reqwidth" without having to use "update"?
You could try to bind to the <Configure> event (widget changes size), or
to <Map> (widget gets displayed). With <Configure> you need to wait for
a notification where the size reported is > 1x1, so it might or might
not help, depending on your needs.

HTH
R'

Thanks Ralf.
I couldn't get the Configure binding working, which should have set a global variable. The vwait to this global variable never completed, meaning the global variable was never set so there was no <Configure> event.
I guess this has something to do with the fact, that I'm trying to display a "menu" type widget which blocks.

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

briang schrieb am Freitag, 10. Dezember 2021 um 22:53:57 UTC+1:

On Friday, December 10, 2021 at 2:05:59 AM UTC-8, Alexandru wrote:

I realized, that the "update" or "update idletasks" command can cause some performance issues when applied in a GUI.

For example: I need to use "update" in order to correctly get values from "winfo reqwidth". This causes a small delay that is perceptible.

The question is: Is there another way to get current values from "winfo reqwidth" without having to use "update"?

Many thanks
Alexandru

It has been my experience that the use of [update], in any form, is rarely the correct answer. The only time it is necessary is in a regression test, and even then it is often problematic.

I would first start by rethinking the problem and find a solution that does not require [update]. Ralf's suggestion is one example of a superior solution to using [update] when needing accurate geometry info.

For [update idletasks] I would suggest using [after idle] as a way to generate a one-time pseudo event to trigger the completion of a task after some prior "idle" task that was scheduled. [after idle] can be used within a coroutine to give the

appearance of sequential coding that may be easer to reason about it's correctness. For example:

wm deiconify $w
after idle [info coroutine]
yield
set geom [winfo geom $w]
...
return

Thanks Brian.
Using "after idle" works.
I got it work without coroutine (for which I still got respect even after reading multiple times the examples).
The coroutine makes the code more simple I guess. Maybe another time.

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

Harald Oehlmann schrieb am Freitag, 10. Dezember 2021 um 14:36:33 UTC+1:

Dear Alexandru,

please find here my 3 cents:

it is normally not the update, but program structure.

On each update, any event driven code may run.
So, if you have io events or after tasks - they may run within the
update and will cause an arbitrary delay.

If Tk has redraws pending, this will happen with the update.
So, here, update can be very slow, but then, the work is done.
Otherwise, the work would be done after your procedure and you would not measure it.

Take care,
Harald
Am 10.12.2021 um 13:27 schrieb Alexandru:

Erik Leunissen schrieb am Freitag, 10. Dezember 2021 um 13:12:10 UTC+1:

On 10/12/2021 11:05, Alexandru wrote:

I realized, that the "update" or "update idletasks" command can cause some performance issues when applied in a GUI.

It matters whether you choose [update idletasks] or [update].

In my experience, a raw [update] is overkill in this case. It may do much more than just induce a
size computation, and therefore it could be a cause of an extra performance penalty.

Erik.

Yes, I know. In my specific case though, it make no difference.
Maybe it's a Windows thing. I don't know. But here is where the theory differs from the practice.

Hi Harald,

Thank you.
It's difficult to answer the question, wether or not my app is causing the time delay in combination with the update command. If I had to guess, I would say "probably not" though I cannot be sure at the moment.

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

On Saturday, December 11, 2021 at 4:48:14 AM UTC-8, Alexandru wrote:

Ralf Fassel schrieb am Freitag, 10. Dezember 2021 um 12:13:20 UTC+1:

* Alexandru <alexandr...@meshparts.de>
| For example: I need to use "update" in order to correctly get values
| from "winfo reqwidth". This causes a small delay that is perceptible.

| The question is: Is there another way to get current values from
| "winfo reqwidth" without having to use "update"?
You could try to bind to the <Configure> event (widget changes size), or
to <Map> (widget gets displayed). With <Configure> you need to wait for
a notification where the size reported is > 1x1, so it might or might
not help, depending on your needs.

HTH
R'

Thanks Ralf.
I couldn't get the Configure binding working, which should have set a global variable. The vwait to this global variable never completed, meaning the global variable was never set so there was no <Configure> event.
I guess this has something to do with the fact, that I'm trying to display a "menu" type widget which blocks.

On Windows and MacOS X the menus are handled natively by the OS. They are not Tk widgets, so there are no Tk events generated by these widgets. Once a menu is posted, your application is no longer in control until the menu is unposted.

This is also true for the Open and Save file dialog boxes.

-Brian

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