Help save net neutrality! Learn more.

#91 Resizing window is very laggy: causes Bristol to quit


In 0.60.10, when resizing the window (of at least the mini emulator), the window contents are redrawn multiple times as the window is resized, and each redraw seems to take a second or two. This causes:

May 2 11:14:58 bristol [19.398419] Active Sensing detected failure of UI
May 2 11:14:58 bristol [19.398633] removing one mini

and Bristol then exits.

Maximising the window works fine: the UI is redrawn once only.


  • Nick Copeland

    Nick Copeland - 2012-05-02

    Is this new to 0.60.10? The issue is known and there are 'workarounds' but with opaque resizing where the WM allows updates dynamically then there is a lot of overhead to resizing. The workarounds are to change the active sense settings with -as and -ast (you can disable active sensing with -as 0 for example) or alternatively to disable opaque resizing in your window manager, well, iwth the ones that support such options.

    Using '-as 0' is not a big issue, the goal of active sensing is to allow the GUI and engine to respectively detect failure of the other component and exit gracefully. It was implemented when code instabilities resulted in processes hanging around after exit - almost a workaround for bugs that should now be fixed.

    If you put '-as 0' in your ~/.bristolrc then you will not have to put it on the commandline each time.

    I am happy to keep this open for the time being. Whilst I am not sure that I can optimise the resizing much there is work going on to make the code 'monolithic', a combined engine and GUI, that does not need active sensing. I don't have release dates for such code nor am I certain whether it will be a 0.70 or 0.80 release.

  • Colin Fletcher

    Colin Fletcher - 2012-05-02

    Ah, '-as 0' seems like a sensible work-around: thank you.

    I never noticed this issue in previous versions: presumably the new vector rendering is just a bit slower on my machine than the old bitmap resizing was, so that the redraw time now exceeds the active sensing timeout.

    Maybe there's something that could be done to optimise the rendering, at least while the window is being resized.

  • Nick Copeland

    Nick Copeland - 2012-05-02

    So the overhead of the vector graphic operations is pushing you over the top. I did not expect it to have so much impact, it is only supposed to scan around the bitmaps changing a few pixel values.

    If it such a small margin then changing the AS timeouts may be enough. I can review optimisation to this code at some point.


Log in to post a comment.