Re: Firefox 3 beta



In article <32Nxj.3292$pl4.1825@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
"ed" <news@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

"ZnU" <znu@xxxxxxxxxxxx> wrote in message
news:znu-1C1A7B.00273529022008@xxxxxxxxxxxxxxxxxxxxxx
In article
<40e5253f-6a0b-4d33-812b-a1e6d3f8b0a5@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
ed <news@xxxxxxxxxxxxxxx> wrote:

On Feb 13, 9:15 pm, Snit <C...@xxxxxxxxxxxxxxxxxxxxx> wrote:
Wow... still not a perfect OS X citizen as far as UI goes but getting
much
better... I am impressed. Have only played with it a few minutes but
so
far
it seems excellent.

interesting read-
http://blog.vlad1.com/2008/02/28/finding-the-os-x-turbo-button/

Not particularly. I know people would like to invoke all those stories
about Microsoft gaining advantage with private APIs, but that doesn't
appear to be what's going on here, for several reasons:

1) WebKit isn't an application. It's a system library. Do people really
think third-party apps should access all the same hooks into the system
that *other parts of the system* do?

isn't that basically the exact same argument ms made regarding internet
explorer back in the day? :P

Sure. But that doesn't mean there aren't actually legitimate reasons to
sometimes keep APIs private.

2) Apple (per David Hyatt's comment) isn't actually happy about using
this internal API and wants to get rid of it.

3) Apple is only using this private API as a workaround to avoid causing
performance issues for older apps that embed WebKit. There's no reason
Firefox should be using this API, rather than the publicly documented
mechanism Apple provides for disabling coalesced updates. (Which is
exactly what Firefox is now doing.)

4) The only reason Firefox needs to disable coalesced updates in the
first place is because of internal inefficiencies that the Firefox team
already plans to optimize out in the future.

yeah... that's the story, but the default behavior is prety whacked...
especially when the in house devs are doing something other than what
they're telling everyone else to do. at least makes you suspicious...

Err? The default behavior is that shiny new Cocoa apps get coalesced
updates, which make things more efficient in the typical case. If
coalesced updates happen to make things slower for your app (usually
because your app is drawing to the screen too often, but that's
sometimes hard to fix), you can turn them off.

Apple doesn't want them getting turned off at runtime though, because
things can blow up when you do that, so Apple provides a documented
mechanism to switch them off at launch. This is the appropriate
mechanism for Firefox to use, and the mechanism it is now using.

WebKit *has* to turn coalesced updates off at runtime, because old apps
that embed it won't know to turn it off at launch time. But this doesn't
mean it's a good idea. In fact, from what Hyatt says, it sounds like
it's a downright bad idea. It's bad enough when you have screwy hacks in
your own code; encouraging others to use them as well is just
irresponsible.

--
"More than two decades later, it is hard to imagine the Revolutionary War coming
out any other way."
                        --George W. Bush in Martinsburg, W. Va., July 4, 2007
.