Over 100 resizes and out of order display at startup

Posted by Fiendish on Mon 04 Jul 2011 08:46 PM — 10 posts, 37,678 views.

Fiendish USA Global Moderator Mon 04 Jul 2011 08:46 PM #0

I just threw this into a plugin loaded at startup to test something:


i = 0
print("hmmm")
function OnPluginWorldOutputResized()
   i = i+1
   print(i)
end

The output I got was this...

Quote:

95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
Welcome to MUSHclient version 4.75!
Written by Nick Gammon.

Compiled: Jun 12 2011.
Using: Lua 5.1.4, PCRE 8.12, PNG 1.5.2, SQLite3 3.7.6.3, Zlib 1.2.5

For information and assistance about MUSHclient visit our forum at:
http://www.gammon.com.au/forum/
Can you trust your plugins? See: http://www.gammon.com.au/security
hmmm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
117
118
119
120
121
122
123

There are two obvious issues here.
First, 123 resizes seems rather excessive.
Second, the output from 95-116 is in the wrong place.

Nick Gammon Australia Forum Administrator Mon 04 Jul 2011 08:50 PM #1

That's Windows for you Fiendish. If I don't pass on the WM_SIZE when I get them when am I supposed to do it?

Fiendish USA Global Moderator Mon 04 Jul 2011 08:52 PM #2

I guess. Any idea about the ordering weirdness?

Twisol USA Mon 04 Jul 2011 09:09 PM #3

Nick Gammon said:
That's Windows for you Fiendish. If I don't pass on the WM_SIZE when I get them when am I supposed to do it?

Many browsers have the same issue with the onresize event. A common practice is to delay the event by 50-100ms, and if another onresize occurs during that period, the timer is reset. It basically waits until the last onresize has arrived.

function delay(f, time) {
  var id = null;
  return function() {
    var context = this;
    var args = Array.prototype.slice(arguments);
    
    if (id) { window.clearTimeout(id); }
    
    id = window.setTimeout(function() {
      id = null;
      f.apply(context, args);
    }, time);
  };
}

$(window).resize(delay(function() {
  // do stuff
}, 100));

Another approach is to wait 100ms from the first onresize and ignore any others until the time is up, at which point you act on the event and start accepting onresize events again. This guarantees a more regular frequency for handling resize events, since you always respond after 100ms. The first approach ensures that only one onresize is handled.

function wait(f, time) {
  var id = null;
  return function() {
    var context = this;
    var args = Array.prototype.slice(arguments);
    
    if (!id) {
      id = setTimeout(function() {
        id = null;
        f.apply(context, args);
      }, time);
    }
  };
}

$(window).resize(wait(function() {
  // do stuff
}, 100));

I suppose this is similar to "debouncing" in electronics, although in that case the event is handled immediately and there's a cooldown. But that's not really what you want in the resize-event case.

[EDIT]: Code examples! I already had the first written, so I threw it in and added the second.

Twisol USA Mon 04 Jul 2011 09:29 PM #4

Fiendish said:
I guess. Any idea about the ordering weirdness?

My only guess is that, for 1-94 the output area wasn't initialized, so they were buffered up. For 95-116 they snuck in after initialization but before the first lines were flushed. Right after 116 the buffer was flushed, and 117-123 came out in the right place.

Nick Gammon Australia Forum Administrator Tue 05 Jul 2011 05:37 AM #5

Fiendish said:

I guess. Any idea about the ordering weirdness?

Well, Windows posts messages (which get queued), it sends them (which don't) and then you have MFC doing who-knows-what before I get them.

If you are going to "debounce" the sizing you may as well do that yourself. Get the resize callback to start some sort of timer, and if the timer already exists, reset it. Then when the timer finally fires, do what you have to do.

Twisol USA Tue 05 Jul 2011 05:45 AM #6

Nick Gammon said:

Fiendish said:

I guess. Any idea about the ordering weirdness?

Fairly sure the issue is about some of the Notes coming out ahead of Notes that fired earlier, not the resizing events quantity.

Nick Gammon Australia Forum Administrator Tue 05 Jul 2011 05:49 AM #7

Oh is that what you meant? I though you were referring to the WM_TIMER messages.

In that case, well spotted. It is an artefact of the world initialisation. I probably would have missed that. :)

Well I *did* miss it. ;)

Twisol USA Tue 05 Jul 2011 05:51 AM #8

Haha, yeah, the thread was about two separate issues. ;) I was talking about delaying the event handling in my first post, then speculating on the note ordering issue in the one immediately following.

Nick Gammon Australia Forum Administrator Tue 05 Jul 2011 05:58 AM #9

Nick Gammon said:

Oh is that what you meant? I though you were referring to the WM_TIMER messages.

Er, WM_SIZE messages.