wx:batch/1 on Windows 10

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

wx:batch/1 on Windows 10

zxq9-2
I have been working on a tool kit to make project creation,
distribution, launching from source, etc. a bit smoother for cross
platform Erlang apps (particularly client-side) and have hit a
susprising snag: wx:batch/1 doesn't seem to have any effect on Windows.

Due to this the GUI app browser and launcher windows populate in a
glitchy way, Observer graphs flicker, and other marginally annoying
phenomena occur -- but only on Windows.

You can observe this by running wx:demo() and selecting any example
frame that has multiple components.

I get this effect with R22.2 on Windows 10, but haven't confirmed how
far back this bug exists (this problem did not occur previously around
the time of R18 on Windows 7).

Would this be an issue with Windows, WX lib version, build config (I'm
using the Windows x64 binary installer), graphics drivers, etc?

Any ideas would be appreciated. It is still possible to write and run
meaningful apps, of course (and they work great on other platforms) but
Windows is a pretty important target for client-side code.

-Craig
Reply | Threaded
Open this post in threaded view
|

Re: wx:batch/1 on Windows 10

Dan Gudmundsson-2
wx:batch() was originally intended as optimization, by not letting wxWidgets get control until the
complete work batch was done. I.e. a faster interface to the executing thread.

I have optimized the code since then and on linux batch is not needed, I have changed
so that events are checked (temporary allow wxWidgets to check/handle events) every forth batch otherwise
event handling could be starved when to many large batches where sent to wx thread.

But I have also noticed the problem, starting observer on a slow computer shows the problem,
and I have tried to revert the changes mentioned above but I have not managed to figure out what
have changed.

One thing that have changed is wxWidgets version, i.e. upgrade from 2.8 to 3.0.3 (soon to be 3.1 on windows),
but I don't know what is causing this, nor how where is should be fixed in the application code,
 wx wrapper or wxwidgets library.


On Tue, Jan 21, 2020 at 10:55 AM zxq9 <[hidden email]> wrote:
I have been working on a tool kit to make project creation,
distribution, launching from source, etc. a bit smoother for cross
platform Erlang apps (particularly client-side) and have hit a
susprising snag: wx:batch/1 doesn't seem to have any effect on Windows.

Due to this the GUI app browser and launcher windows populate in a
glitchy way, Observer graphs flicker, and other marginally annoying
phenomena occur -- but only on Windows.

You can observe this by running wx:demo() and selecting any example
frame that has multiple components.

I get this effect with R22.2 on Windows 10, but haven't confirmed how
far back this bug exists (this problem did not occur previously around
the time of R18 on Windows 7).

Would this be an issue with Windows, WX lib version, build config (I'm
using the Windows x64 binary installer), graphics drivers, etc?

Any ideas would be appreciated. It is still possible to write and run
meaningful apps, of course (and they work great on other platforms) but
Windows is a pretty important target for client-side code.

-Craig
Reply | Threaded
Open this post in threaded view
|

Re: wx:batch/1 on Windows 10

zxq9-2
On 2020/01/21 19:47, Dan Gudmundsson wrote:

> wx:batch() was originally intended as optimization, by not letting
> wxWidgets get control until the
> complete work batch was done. I.e. a faster interface to the executing
> thread.
>
> I have optimized the code since then and on linux batch is not needed, I
> have changed
> so that events are checked (temporary allow wxWidgets to check/handle
> events) every forth batch otherwise
> event handling could be starved when to many large batches where sent to
> wx thread.
>
> But I have also noticed the problem, starting observer on a slow
> computer shows the problem,
> and I have tried to revert the changes mentioned above but I have not
> managed to figure out what
> have changed.
>
> One thing that have changed is wxWidgets version, i.e. upgrade from 2.8
> to 3.0.3 (soon to be 3.1 on windows),
> but I don't know what is causing this, nor how where is should be fixed
> in the application code,
>   wx wrapper or wxwidgets library.

I've just tested R17 through R22.2 and they all have this issue on
Windows 10, which surprises me. I'll go back and check Windows 7 later,
and see if I can find some other graphics hardware to see if that makes
a difference.

Anyway, wxWindow:freeze/1 and wxWindow:thaw/1 both exist on our
interface, so I might be able to make this work as expected using this
technique directly. I'll let you know how it goes.

I'm not sure about the flicker on Windows with Observer graphs. The
difference in refresh rate is really surprising. May just need more
explicit control of when to blit:
https://wiki.wxwidgets.org/Flicker-Free_Drawing

GL canvasses work beautifully, by the way, so no trouble there so far.
(Too bad 3D widget sets/interfaces aren't the norm!)

-Craig
Reply | Threaded
Open this post in threaded view
|

Re: wx:batch/1 on Windows 10

zxq9-2
In reply to this post by Dan Gudmundsson-2
On 2020/01/21 20:16, Dan Gudmundsson wrote:
>      > One thing that have changed is wxWidgets version, i.e. upgrade
>     from 2.8
>      > to 3.0.3 (soon to be 3.1 on windows),
>      > but I don't know what is causing this, nor how where is should be
>     fixed
>      > in the application code,
>      >   wx wrapper or wxwidgets library.

Hi, again.

After confirming the behavior (and also finding that freeze/1, [make
stuff], thaw/1 doesn't work on Windows) someone in the SO Erlang channel
found this bug that has been around forever and seems to apply only to
wxMSW:

https://trac.wxwidgets.org/ticket/10748

The description is exactly the problem I see. Hopefully they'll get this
cleared up. It is a very weird problem. I imagine I can create a
workaround, but will need a few hours to mess with it to figure out a way.

If they fix freeze/thaw on all platforms then a non-hacky implementation
of batch/1 could be:


   -spec batch(Window, Fun) -> Result
       when Window :: wx:wx_object(),
            Fun    :: fun(),
            Result :: term().

   batch(Window, Fun) ->
       ok = wxWindow:freeze(Window),
       Result = Fun(),
       ok = wxWindow:thaw(Window),
       Result.

Fingers crossed this is addressed in 3.1.

-Craig
Reply | Threaded
Open this post in threaded view
|

Re: wx:batch/1 on Windows 10

Dmitry Belyaev-3
Maybe

batch(Window, Fun) ->
ok = wxWindow:freeze(Window),
try
Fun()
after ->
ok = wxWindow:thaw(Window)
end.

would be better

On 26 January 2020 12:59:23 pm AEDT, zxq9 <[hidden email]> wrote:
On 2020/01/21 20:16, Dan Gudmundsson wrote:
One thing that have changed is wxWidgets version, i.e. upgrade
from 2.8
to 3.0.3 (soon to be 3.1 on windows),
but I don't know what is causing this, nor how where is should be
fixed
in the application code,
   wx wrapper or wxwidgets library.

Hi, again.

After confirming the behavior (and also finding that freeze/1, [make
stuff], thaw/1 doesn't work on Windows) someone in the SO Erlang channel
found this bug that has been around forever and seems to apply only to
wxMSW:

https://trac.wxwidgets.org/ticket/10748

The description is exactly the problem I see. Hopefully they'll get this
cleared up. It is a very weird problem. I imagine I can create a
workaround, but will need a few hours to mess with it to figure out a way.

If they fix freeze/thaw on all platforms then a non-hacky implementation
of batch/1 could be:


-spec batch(Window, Fun) -> Result
when Window :: wx:wx_object(),
Fun :: fun(),
Result :: term().

batch(Window, Fun) ->
ok = wxWindow:freeze(Window),
Result = Fun(),
ok = wxWindow:thaw(Window),
Result.

Fingers crossed this is addressed in 3.1.

-Craig

--
Kind regards,
Dmitry Belyaev
Reply | Threaded
Open this post in threaded view
|

Re: wx:batch/1 on Windows 10

zxq9-2
On 2020/01/28 9:22, Dmitry Belyaev wrote:

> Maybe
>
> batch(Window, Fun) ->
> ok = wxWindow:freeze(Window),
> try
> Fun()
> after ->
> ok = wxWindow:thaw(Window)
> end.
>
> would be better

What would be better about that? If there is a problem in the GUI update
  (Fun()) the last thing I want to have happen is the Erlang half
sticking around.

-Craig
Reply | Threaded
Open this post in threaded view
|

Re: wx:batch/1 on Windows 10

Dmitry Belyaev-3
I just wanted to remind of error handling and assumed a completely frozen UI is worse than the UI with only some components added, especially in a generic 'batch'.

I wasn't sure about your particular use case, so I added "maybe".

On 28 January 2020 11:28:30 am AEDT, zxq9 <[hidden email]> wrote:
On 2020/01/28 9:22, Dmitry Belyaev wrote:
Maybe

batch(Window, Fun) ->
ok = wxWindow:freeze(Window),
try
Fun()
after ->
ok = wxWindow:thaw(Window)
end.

would be better

What would be better about that? If there is a problem in the GUI update
(Fun()) the last thing I want to have happen is the Erlang half
sticking around.

-Craig

--
Kind regards,
Dmitry Belyaev