Remove EventQueueHandler stuff from Cocoa nsToolkit



Camino Graveyard
15 years ago
13 years ago


(Reporter: Simon Fraser, Assigned: Mike Pinkerton (not reading bugmail))


Mac OS X




15 years ago
Now that plevent.c does its own Carbon Event stuff for PLEvent handling, we
don't need the NSTimer/ProcessPendingEvents in EventQueueHandler. We should just
be able to remove it.


15 years ago
Blocks: 197865

Comment 1

15 years ago
it works, i'm doing opt builds to run page-load tests (before and after)

Comment 2

15 years ago
bad news. i turned on the carbon event code in plevent.c and removed the
EventQueueHandler timer code from the toolkit and we got a big slowdown.

trunk, using timer:
  run 1: 894 run 2: 778

trunk, using carbon events:
  run 1: 914 run 2: 881

run two is almost a 12% slowdown. you can see the speed difference as well while
running the tests. with the timer, most pages snap in whole. with the carbon
event, they come in, then jiggle once or twice.

are we not handling the list of events as optimally as we should?

Comment 3

15 years ago
i even tried varying the carbon event's priority (the code on the tip uses low
priority). here's what i got:

using carbon events, standard priority
  run 1: 909 run 2: 899

using carbon events, high priority
  run 1: 905

*sigh* :(
I wonder if the effect of using Carbon Events in plevent.c favors a slow
connection? On bug 44768, see comment 53, when I had a fast connection, and
comment 65, when I had a slower connection. Either that, or it behaves
differently in a Cocoa app?
It does seem to be very dependent on connection speed. Here's what I got by: 
removing Cache dir, and running cowtools 3 cycles

CarbonEvent - avg median: 1566
Timer - avg median: 2104

Comment 6

15 years ago
Assignee: saari → ccarlen
I think this needs some more testing and maybe discussion. Results vary a lot
depending on what speed of connection you have. If one approach can't be clearly
better across the spectrum, what part of the spectrum do we aim to please?

Comment 8

14 years ago
i don't even think this bug is valid anymore, is it?

Comment 9

14 years ago
gonna give this one last shot to see what the numbers look like. i'll put a
patch up shortly.
Assignee: ccarlen → pinkerton
Target Milestone: --- → Camino0.8

Comment 10

14 years ago
we're gonna leave this as-is for now and investigate ways that aren't so tied up
in the event loop and jockeying for position with redraw events, etc.
Target Milestone: Camino0.8 → Camino0.9

Comment 11

13 years ago
i think we can safely dupe this to 271050. please comment over there.

*** This bug has been marked as a duplicate of 271050 ***
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.