cleaning all sizers recursively ?

[Ludovic Aubert]

Hello,

I have following issue:
I have a dialog box where, using a wxBoxSizer having several sub wxBoxSizer
added to it, several controls are laid out.
It also has a combo (being one of the controls), and if this combo is
selected, the whole dialog might get rebuilt.
It is rebuilt simply by calling dialog->DestroyChildren(); and then the
sizers and the controls are created again and laid out.

It all works fine ... but ...
an interesting case is using a wxDialog having a wxScrolledWindow having
400 wxCheckBox.
wxDialog
|
+----> wxScrolledWindow
|
+------- wxCheckBox
|
+------- wxCheckBox
|
+------ ...
At dialog creation, the whole dialog is created in a flash, but on rebuild
it takes about 4 seconds,
as a single call to 'new wxCheckBox' takes in the order of 0.02 sec.

I think some nasty sizers are still hanging around and slowing things down,
but I am not sure and I don't know the easiest way to get rid of them
without to much iteration.

Any help appreciated

thanks in advance
Ludovic

[Ludovic Aubert]

Sorry, I forgot to mention:
under Windows7 using a wxwidgets 2.9.5.
Strange, how can 'new wxCheckBox' take 0.02 s during dialog children
rebuild, as it took only about 0.0001 s during initial dialog children
build.
any Cherlock Holmes ?

Post by Ludovic Aubert
Hello,
I have a dialog box where, using a wxBoxSizer having several sub
wxBoxSizer added to it, several controls are laid out.
It also has a combo (being one of the controls), and if this combo is
selected, the whole dialog might get rebuilt.
It is rebuilt simply by calling dialog->DestroyChildren(); and then the
sizers and the controls are created again and laid out.
It all works fine ... but ...
an interesting case is using a wxDialog having a wxScrolledWindow having
400 wxCheckBox.
wxDialog
|
+----> wxScrolledWindow
|
+------- wxCheckBox
|
+------- wxCheckBox
|
+------ ...
At dialog creation, the whole dialog is created in a flash, but on rebuild
it takes about 4 seconds,
as a single call to 'new wxCheckBox' takes in the order of 0.02 sec.
I think some nasty sizers are still hanging around and slowing things
down, but I am not sure and I don't know the easiest way to get rid of them
without to much iteration.
Any help appreciated
thanks in advance
Ludovic

[Ludovic Aubert]

Post by Ludovic Aubert
Hello,
I have a dialog box where, using a wxBoxSizer having several sub
wxBoxSizer added to it, several controls are laid out.
It also has a combo (being one of the controls), and if this combo is
selected, the whole dialog might get rebuilt.
It is rebuilt simply by calling dialog->DestroyChildren(); and then the
sizers and the controls are created again and laid out.
It all works fine ... but ...
an interesting case is using a wxDialog having a wxScrolledWindow having
400 wxCheckBox.
wxDialog
|
+----> wxScrolledWindow
|
+------- wxCheckBox
|
+------- wxCheckBox
|
+------ ...
At dialog creation, the whole dialog is created in a flash, but on rebuild
it takes about 4 seconds,
as a single call to 'new wxCheckBox' takes in the order of 0.02 sec.
I think some nasty sizers are still hanging around and slowing things
down, but I am not sure and I don't know the easiest way to get rid of them
without to much iteration.
Any help appreciated
thanks in advance
Ludovic

I tried adding a call to :

void detach(wxWindow* win)
{
if (wxSizer *sizer = win->GetContainingSizer())
sizer->Detach(win);
for (wxWindow* child_win : win->GetChildren())
detach(child_win);
}

before the call to DestroyChildren() but it didn't solve the issue

[Xaviou]

Hi

Post by Ludovic Aubert
Hello,
I have a dialog box where, using a wxBoxSizer having several sub
wxBoxSizer added to it, several controls are laid out.
It also has a combo (being one of the controls), and if this combo is
selected, the whole dialog might get rebuilt.
It is rebuilt simply by calling dialog->DestroyChildren(); and then the
sizers and the controls are created again and laid out.
It all works fine ... but ...
an interesting case is using a wxDialog having a wxScrolledWindow having
400 wxCheckBox.
wxDialog
|
+----> wxScrolledWindow
|
+------- wxCheckBox
|
+------- wxCheckBox
|
+------ ...
At dialog creation, the whole dialog is created in a flash, but on rebuild
it takes about 4 seconds,
as a single call to 'new wxCheckBox' takes in the order of 0.02 sec.
I think some nasty sizers are still hanging around and slowing things
down, but I am not sure and I don't know the easiest way to get rid of them
without to much iteration.
Any help appreciated
thanks in advance
Ludovic

It is possible that the problem comes from the fact that the dialog is
shown when you rebuild the content of your dialog (but it is hidden at
creation time).
You should try using "Freeze / Thaw" when destroying and re-creating your
controls.

Regards
Xav'

[Ludovic Aubert]

Hello,

thank you for the idea to use Freeze()+Thaw(). I really thought it might
work, but it did not speed things up.
The mystery remains :)
Ludovic

Post by Ludovic Aubert
Hello,
I have a dialog box where, using a wxBoxSizer having several sub
wxBoxSizer added to it, several controls are laid out.
It also has a combo (being one of the controls), and if this combo is
selected, the whole dialog might get rebuilt.
It is rebuilt simply by calling dialog->DestroyChildren(); and then the
sizers and the controls are created again and laid out.
It all works fine ... but ...
an interesting case is using a wxDialog having a wxScrolledWindow having
400 wxCheckBox.
wxDialog
|
+----> wxScrolledWindow
|
+------- wxCheckBox
|
+------- wxCheckBox
|
+------ ...
At dialog creation, the whole dialog is created in a flash, but on rebuild
it takes about 4 seconds,
as a single call to 'new wxCheckBox' takes in the order of 0.02 sec.
I think some nasty sizers are still hanging around and slowing things
down, but I am not sure and I don't know the easiest way to get rid of them
without to much iteration.
Any help appreciated
thanks in advance
Ludovic

[Xaviou]

Hi

Post by Ludovic Aubert
Hello,
thank you for the idea to use Freeze()+Thaw(). I really thought it might
work, but it did not speed things up.
The mystery remains :)
Ludovic

Strange. I also really thought the problem was coming from that point...

Could you post the part of code responsible of the re-creation of the
controls : perhaps we'll see something.

Regards
Xav'

[Vadim Zeitlin]

On Wed, 16 Apr 2014 13:43:45 +0200 Ludovic Aubert wrote:

LA> It all works fine ... but ...
LA> an interesting case is using a wxDialog having a wxScrolledWindow having
LA> 400 wxCheckBox.
LA> wxDialog
LA> |
LA> +----> wxScrolledWindow
LA> |
LA> +------- wxCheckBox
LA> |
LA> +------- wxCheckBox
LA> |
LA> +------ ...
LA> At dialog creation, the whole dialog is created in a flash, but on rebuild
LA> it takes about 4 seconds,
LA> as a single call to 'new wxCheckBox' takes in the order of 0.02 sec.
LA>
LA> I think some nasty sizers are still hanging around and slowing things down,
LA> but I am not sure and I don't know the easiest way to get rid of them
LA> without to much iteration.

Normally if you delete the wxScrolledWindow itself, it should
automatically delete all its children without doing any extra layouts. If
you still have a significant delay when doing it like this, I'd be
interested in having a small patch to the minimal sample reproducing the
problem as it shouldn't happen like this AFAICS.

Regards,
VZ

[Ludovic Aubert]

Hello,

here is the C++ code that reproduces the slow dialog rebuild I was writing
about. Hope there is a way to improve this :)

Ludovic

Post by Vadim Zeitlin
LA> It all works fine ... but ...
LA> an interesting case is using a wxDialog having a wxScrolledWindow having
LA> 400 wxCheckBox.
LA> wxDialog
LA> |
LA> +----> wxScrolledWindow
LA> |
LA> +------- wxCheckBox
LA> |
LA> +------- wxCheckBox
LA> |
LA> +------ ...
LA> At dialog creation, the whole dialog is created in a flash, but on rebuild
LA> it takes about 4 seconds,
LA> as a single call to 'new wxCheckBox' takes in the order of 0.02 sec.
LA>
LA> I think some nasty sizers are still hanging around and slowing things down,
LA> but I am not sure and I don't know the easiest way to get rid of them
LA> without to much iteration.
Normally if you delete the wxScrolledWindow itself, it should
automatically delete all its children without doing any extra layouts. If
you still have a significant delay when doing it like this, I'd be
interested in having a small patch to the minimal sample reproducing the
problem as it shouldn't happen like this AFAICS.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Vadim Zeitlin]

On Mon, 21 Apr 2014 11:05:18 +0200 Ludovic Aubert wrote:

LA> here is the C++ code that reproduces the slow dialog rebuild I was writing
LA> about. Hope there is a way to improve this :)
...
LA> > Normally if you delete the wxScrolledWindow itself, it should
LA> > automatically delete all its children without doing any extra layouts.

Well, the first step would be to do what I wrote above -- and which isn't
done by the code you posted AFAICS. It would also be great to have
something that can actually be built without changes (which is why a patch
to the minimal sample would be ideal), which is not the case of this code
because it doesn't define any entry point and so doesn't link.

Regards,
VZ

[Ludovic Aubert]

to build it without changes, all you need to do is call wxmain from wxapp.
Sorry you don t like it because it took some effort to write and it is the
min amount of code you need to reproduce the phenomenon. Doesnt
destroychildren delete the wxscrolledwindow? additional info is that the
rebuild time seems independant of the number of controls before the call to
rebuild. i ll be away from my computer one week so i can make a patch but
you will have to wait and i am not doing it often. all you need to do with
the code i sent is call wxmain to let the dialog show up.
regards
ludovic

Post by Vadim Zeitlin
LA> here is the C++ code that reproduces the slow dialog rebuild I was writing
LA> about. Hope there is a way to improve this :)
...
LA> > Normally if you delete the wxScrolledWindow itself, it should
LA> > automatically delete all its children without doing any extra layouts.
Well, the first step would be to do what I wrote above -- and which isn't
done by the code you posted AFAICS. It would also be great to have
something that can actually be built without changes (which is why a patch
to the minimal sample would be ideal), which is not the case of this code
because it doesn't define any entry point and so doesn't link.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Ludovic Aubert]

i just realized that Freeze is not recursive. i only tried to call it on
the dialog itself. should have called it on the wxscrolledwindow
instead.Xav you might be right after all ! I ll let you know.
ludovic

Post by Ludovic Aubert
to build it without changes, all you need to do is call wxmain from wxapp.
Sorry you don t like it because it took some effort to write and it is the
min amount of code you need to reproduce the phenomenon. Doesnt
destroychildren delete the wxscrolledwindow? additional info is that the
rebuild time seems independant of the number of controls before the call to
rebuild. i ll be away from my computer one week so i can make a patch but
you will have to wait and i am not doing it often. all you need to do with
the code i sent is call wxmain to let the dialog show up.
regards
ludovic

Post by Vadim Zeitlin
LA> here is the C++ code that reproduces the slow dialog rebuild I was writing
LA> about. Hope there is a way to improve this :)
...
LA> > Normally if you delete the wxScrolledWindow itself, it should
LA> > automatically delete all its children without doing any extra layouts.
Well, the first step would be to do what I wrote above -- and which isn't
done by the code you posted AFAICS. It would also be great to have
something that can actually be built without changes (which is why a patch
to the minimal sample would be ideal), which is not the case of this code
because it doesn't define any entry point and so doesn't link.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Ludovic Aubert]

Hello,

Here is the modified minimal sample. I still don't have any clue. A trial
to call Freeze()+Thaw() resulted in a crash. With this minimal sample, I
could reproduce the phenomenon that initially the dialog shows up with no
delay. If you press the rebuild button it takes in the order of 5 seconds.
Thanks you in advance if somebody can tell me more.

Regards
Ludovic

Post by Ludovic Aubert
i just realized that Freeze is not recursive. i only tried to call it on
the dialog itself. should have called it on the wxscrolledwindow
instead.Xav you might be right after all ! I ll let you know.
ludovic

Post by Ludovic Aubert
to build it without changes, all you need to do is call wxmain from
wxapp. Sorry you don t like it because it took some effort to write and it
is the min amount of code you need to reproduce the phenomenon. Doesnt
destroychildren delete the wxscrolledwindow? additional info is that the
rebuild time seems independant of the number of controls before the call to
rebuild. i ll be away from my computer one week so i can make a patch but
you will have to wait and i am not doing it often. all you need to do with
the code i sent is call wxmain to let the dialog show up.
regards
ludovic

Post by Vadim Zeitlin
LA> here is the C++ code that reproduces the slow dialog rebuild I was writing
LA> about. Hope there is a way to improve this :)
...
LA> > Normally if you delete the wxScrolledWindow itself, it should
LA> > automatically delete all its children without doing any extra layouts.
Well, the first step would be to do what I wrote above -- and which isn't
done by the code you posted AFAICS. It would also be great to have
something that can actually be built without changes (which is why a patch
to the minimal sample would be ideal), which is not the case of this code
because it doesn't define any entry point and so doesn't link.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Vadim Zeitlin]

On Sun, 27 Apr 2014 05:17:55 -0700 (PDT) Ludovic Aubert wrote:

LA> Here is the modified minimal sample.

For the record: I promised that I'd take a look at this, so I did, but I
have to say that this is as far from what I was looking for when I asked
you for a patch to the minimal sample as it could get. You probably know
this already but if you really misunderstood me so badly, please do read
http://trac.wxwidgets.org/wiki/HowToSubmitPatches and ask here if you have
any questions about it.

LA> I still don't have any clue. A trial to call Freeze()+Thaw() resulted
LA> in a crash.

Inserting the calls to scrolled_win->Freeze() and Thaw() around the
_build() call in "case SCROLLED_WINDOW:" brings the recreation time down to
an acceptable (if still noticeable) time for me.

LA> With this minimal sample, I could reproduce the phenomenon
LA> that initially the dialog shows up with no delay. If you press the
LA> rebuild button it takes in the order of 5 seconds.

I didn't bother to measure it, but the time here is of order of 200ms
perhaps with Freeze/Thaw. It is indeed several seconds without them.

Regards,
VZ

[Ludovic Aubert]

Thank you. That closes the issue.
Ludovic

Post by Vadim Zeitlin
LA> Here is the modified minimal sample.
For the record: I promised that I'd take a look at this, so I did, but I
have to say that this is as far from what I was looking for when I asked
you for a patch to the minimal sample as it could get. You probably know
this already but if you really misunderstood me so badly, please do read
http://trac.wxwidgets.org/wiki/HowToSubmitPatches and ask here if you have
any questions about it.
LA> I still don't have any clue. A trial to call Freeze()+Thaw() resulted
LA> in a crash.
Inserting the calls to scrolled_win->Freeze() and Thaw() around the
_build() call in "case SCROLLED_WINDOW:" brings the recreation time down to
an acceptable (if still noticeable) time for me.
LA> With this minimal sample, I could reproduce the phenomenon
LA> that initially the dialog shows up with no delay. If you press the
LA> rebuild button it takes in the order of 5 seconds.
I didn't bother to measure it, but the time here is of order of 200ms
perhaps with Freeze/Thaw. It is indeed several seconds without them.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/