wx:batch/1 on Windows 10

[zxq9]

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