Closed Bug 106689 Opened 20 years ago Closed 6 years ago

[META] Tracking bug for CarbonEvent transition

Categories

(Core Graveyard :: Widget: Mac, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: mikepinkerton, Assigned: mark)

References

Details

meta-bug to track the work for CarbonEvents.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
Blocks: 102998
Depends on: 106691
Depends on: 106692
Depends on: 106693
Depends on: 106695
Target Milestone: mozilla0.9.6 → mozilla0.9.7
I'm sure this has been covered, but can anybody summarize the cost/
benefits of this?
*** Bug 76901 has been marked as a duplicate of this bug. ***
Benefits:

• Faster connections, fewer failed connections (polling the event manager slowly
like Mozilla does often fails to catch the three way handshake).

• Play animated GIFs at the correct speed.

• Faster 'boot-up' time (you can simulate the effect by clicking down on the
splash screen)

• Play Flash movies correctly

• Doesn't pause any tasks when using the menu or title bar.

• Better overall responsiveness

• No more losing up-click when quickly clicking the title bar

• Will no longer use CPU when idle. 


I'm sure there are more, but that's a starter list. 
> • Faster connections, fewer failed connections (polling the event manager slowly
> like Mozilla does often fails to catch the three way handshake).

Can you explain this more? I'm not aware of any issues with lost connections.
-> 098
Target Milestone: mozilla0.9.7 → mozilla0.9.8
No longer blocks: 102998
Blocks: 102998
not gonna happen in 098
Target Milestone: mozilla0.9.8 → mozilla0.9.9
over to dagley, i probably won't have time for these by 099 with the embedding
work i'm getting pulled into.
Assignee: pinkerton → sdagley
Status: ASSIGNED → NEW
-> mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.1
not going to do full transition to carbon events for mozilla 1.0
No longer blocks: 102998
*** Bug 151921 has been marked as a duplicate of this bug. ***
Are we ever going to do this? In my opinion, it would be a waste to do both this
and to rewrite widget in cocoa (already partially done and necessary for
chimera) because cocoa offers all of the benefits of CarbonEvents and more.
After all, doing this right would probably require a rewrite of a large portion
of widget anyway.
Whether it gets fixed through cocoa-izing the widgets or by writing
CarbonEvents,  either way it would be nice to stop wasting so many CPU cycles. A
shame this set of bugs have been at a standstill so long.

Mozilla (any OSX non-mach build) typically sucks up 4% of my CPU while it's
inactive with no windows open, and much more if I leave an open window with a
few tabs in the background. Chimera exhibits similar behavior, BTW.
Is bug 168611 a duplicate of this bug or a seperate bug?
Target Milestone: mozilla1.1alpha → ---
Since I don't report into Internet Technologies anymore this bug needs a new
owner -> saari
Assignee: sdagley → saari
Depends on: 158859
See also bug 332579.
Assignee: saari → mark
Component: XP Toolkit/Widgets → Widget: Mac
We're part of the way there.  EventRecord-type events are now handled as Carbon events outside and don't use WaitNextEvent, but are still converted to EventRecords and processed through the old dispatcher.  Reference bug 332579 (1.8 branch), bug 326273 (trunk), bug 338153 (consolidating 1.8 branch and trunk implementations).
QA Contact: jrgmorrison → mac
Product: Core → Core Graveyard
RIP Carbon
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.