[Evan Huus <eapache@xxxxxxxxx>]

It should be fixed in r51914 (see the commit message for more details). Joerg, please let me know if it now works for you (or if you are in fact seeing a different bug).

Evan

On Mon, Sep 9, 2013 at 8:58 PM, Evan Huus <eapache@xxxxxxxxx> wrote:

Got it, though I'm not sure the optimal fix - basically, the problem is that when a Paint takes more than info_update_freq_ milliseconds then every single event causes a Paint (because just the last Paint took enough time to trigger the timer). I will dig further

On Mon, Sep 9, 2013 at 8:47 PM, Evan Huus <eapache@xxxxxxxxx> wrote:

On Mon, Sep 9, 2013 at 6:48 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:

On 9/9/13 3:18 PM, Joerg Mayer wrote:
> On Mon, Sep 09, 2013 at 05:38:27PM -0400, Evan Huus wrote:
>> This is actually quite reproducible (on my machine at least). If I maximize
>> the qtshark window immediately upon startup then the splash seems to do a
>> full-window redraw for every change, and takes a significantly
>> longer-than-usual amount of time to finish.
>
> Ah, that explains that last time I got annoyed by this it was more like
> 1,75 minutes. The window was larger.

What happens if you disable antialiasing in the overlay or set its
opacity to 1.0? I can't duplicate this (to any appreciable level, at
least) on any of my test machines.

No change - the splash is marginally faster in general, but it still slows down substantially when the window size is changed. I suspect it's some condition that is accidentally disabling the "Only update every splash_register_freq milliseconds" check, I will try and debug further.