[OSX] Don't create deferred windows.

[OSX] Don't create deferred windows.

Most Chromium windows are created then displayed immediately, which
mostly defeats the purpose of deferring creation of the windowserver
window.  In case of resource exhaustion, this can cause exception
failures to happen at first display rather than when the window is
created.

BUG=481212
Committed: https://crrev.com/fa89814df86cd44a8bae29f3b7889a924eab61c9
Cr-Commit-Position: refs/heads/master@{#332416}

[Scott Hess - ex-Googler, 2015-06-01 19:39:51]

The CQ bit was checked by shess@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-06-01 19:42:59]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1154013009/1

[commit-bot: I haz the power, 2015-06-01 21:04:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-01 21:04:38]

Dry run: This issue passed the CQ dry run.

[Scott Hess - ex-Googler, 2015-06-01 22:11:05]

shess@chromium.org changed reviewers:
+ avi@chromium.org

[Scott Hess - ex-Googler, 2015-06-01 22:11:06]

Periodically I notice things like the bug in question, and it makes me suspect
that there really aren't any cases where Chrome can productively make use of
deferred windows.  WDYT?

[Avi (use Gerrit), 2015-06-02 15:00:57]

On 2015/06/01 22:11:06, Scott Hess wrote:
> Periodically I notice things like the bug in question, and it makes me suspect
> that there really aren't any cases where Chrome can productively make use of
> deferred windows.  WDYT?

Yeah. The whole "defer" thing feels like a leftover from the 68k NeXT days when
you were cycle counting and freaking out about efficiency.

LGTM

[Scott Hess - ex-Googler, 2015-06-02 16:37:33]

The CQ bit was checked by shess@chromium.org

[commit-bot: I haz the power, 2015-06-02 16:38:44]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1154013009/1

[Scott Hess - ex-Googler, 2015-06-02 16:42:27]

On 2015/06/02 15:00:57, Avi wrote:
> On 2015/06/01 22:11:06, Scott Hess wrote:
> > Periodically I notice things like the bug in question, and it makes me
suspect
> > that there really aren't any cases where Chrome can productively make use of
> > deferred windows.  WDYT?
> 
> Yeah. The whole "defer" thing feels like a leftover from the 68k NeXT days
when
> you were cycle counting and freaking out about efficiency.
> 
> LGTM

We only had like 16M of memory back then!  I think the big change is that
everyone just groups their windows into xibs by usage, so it's not nearly so
convenient as it used to be.  Back then you'd maybe just mark your Info panel
deferred and wire a menu item to message -orderFront: and you were done.  These
days you just let some InfoPanelKit you downloaded from github handle all that.

[commit-bot: I haz the power, 2015-06-02 16:48:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-02 16:48:35]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Scott Hess - ex-Googler, 2015-06-02 16:57:54]

shess@chromium.org changed reviewers:
+ sky@chromium.org

[Scott Hess - ex-Googler, 2015-06-02 16:57:54]

On 2015/06/02 16:48:35, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

Grr, yes I see you more clearly now, ui/views/.  +sky

[sky, 2015-06-02 17:04:43]

LGTM

[Scott Hess - ex-Googler, 2015-06-02 17:05:27]

The CQ bit was checked by shess@chromium.org

[commit-bot: I haz the power, 2015-06-02 17:10:05]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1154013009/1

[commit-bot: I haz the power, 2015-06-02 17:16:42]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-06-02 17:17:33]

Patchset 1 (id:??) landed as
https://crrev.com/fa89814df86cd44a8bae29f3b7889a924eab61c9
Cr-Commit-Position: refs/heads/master@{#332416}

[Scott Hess - ex-Googler, 2015-06-05 22:10:13]

Avi, http://crbug.com/496116 is complaining about a perf regression from this
for startup.warm.blank_page .  I _think_ I've isolated it to
framed_browser_window.mm, which makes sense, as that's likely the only one of
these which is in line for that test.

I'm trying to reason out why this would matter.  About all I can think of is
that Chromium might be doing a notable amount of window manipulation before
display, such as resizing the window and manually placing views in it.  With the
deferred window, these operations are probably short-circuited for the parts of
the implementation which actually touch the backing store.

Thinking along those lines makes me wonder if Chromium should default to the
_opposite_ choice, create windows always deferred.  With a regular Cocoa app,
usually everything is loaded from a xib rather than being manually constructed,
I think it's plausible that there will be little churn (or that Cocoa have
provisions to suppress the churn until the xib is fully loaded).  I'm less
confident on the Chromium side.  I recently was instrumenting to debug bug
468201 (an info bubble which pops up), and it was going through the window
layout code four or five times before the child window was finally placed.  I'd
expect many of our uses to be similar.

Is this reasoning insane?

[Scott Hess - ex-Googler, 2015-06-05 22:50:14]

On 2015/06/05 22:10:13, Scott Hess wrote:
> Avi, http://crbug.com/496116 is complaining about a perf regression from this
> for startup.warm.blank_page .  I _think_ I've isolated it to
> framed_browser_window.mm, which makes sense, as that's likely the only one of
> these which is in line for that test.
> 
> I'm trying to reason out why this would matter.  About all I can think of is
> that Chromium might be doing a notable amount of window manipulation before
> display, such as resizing the window and manually placing views in it.  With
the
> deferred window, these operations are probably short-circuited for the parts
of
> the implementation which actually touch the backing store.
> 
> Thinking along those lines makes me wonder if Chromium should default to the
> _opposite_ choice, create windows always deferred.  With a regular Cocoa app,
> usually everything is loaded from a xib rather than being manually
constructed,
> I think it's plausible that there will be little churn (or that Cocoa have
> provisions to suppress the churn until the xib is fully loaded).  I'm less
> confident on the Chromium side.  I recently was instrumenting to debug bug
> 468201 (an info bubble which pops up), and it was going through the window
> layout code four or five times before the child window was finally placed. 
I'd
> expect many of our uses to be similar.
> 
> Is this reasoning insane?

OMG, my brain just suggested that maybe defer:YES was a hack added to support
early manual-setup apps or ports, and the whole "It's so you can have the
convenient Cocoa object hierarchy without the costly backing store" story was
just a retcon to cover their embarrassment.  Because if you're _really_ that
memory and CPU constrained, why would you spend memory and CPU manufacturing
object hierarchies you aren't going to use?

And what about retained backing store!?!!  Maybe this would be a good time to
head home for the weekend...

[Avi (use Gerrit), 2015-06-06 05:51:45]

On 2015/06/05 22:50:14, Scott Hess wrote:
> On 2015/06/05 22:10:13, Scott Hess wrote:
> > Avi, http://crbug.com/496116 is complaining about a perf regression from
this
> > for startup.warm.blank_page .  I _think_ I've isolated it to
> > framed_browser_window.mm, which makes sense, as that's likely the only one
of
> > these which is in line for that test.
> > 
> > I'm trying to reason out why this would matter.  About all I can think of is
> > that Chromium might be doing a notable amount of window manipulation before
> > display, such as resizing the window and manually placing views in it.  With
> the
> > deferred window, these operations are probably short-circuited for the parts
> of
> > the implementation which actually touch the backing store.
> > 
> > Thinking along those lines makes me wonder if Chromium should default to the
> > _opposite_ choice, create windows always deferred.  With a regular Cocoa
app,
> > usually everything is loaded from a xib rather than being manually
> constructed,
> > I think it's plausible that there will be little churn (or that Cocoa have
> > provisions to suppress the churn until the xib is fully loaded).  I'm less
> > confident on the Chromium side.  I recently was instrumenting to debug bug
> > 468201 (an info bubble which pops up), and it was going through the window
> > layout code four or five times before the child window was finally placed. 
> I'd
> > expect many of our uses to be similar.
> > 
> > Is this reasoning insane?
> 
> OMG, my brain just suggested that maybe defer:YES was a hack added to support
> early manual-setup apps or ports, and the whole "It's so you can have the
> convenient Cocoa object hierarchy without the costly backing store" story was
> just a retcon to cover their embarrassment.  Because if you're _really_ that
> memory and CPU constrained, why would you spend memory and CPU manufacturing
> object hierarchies you aren't going to use?
> 
> And what about retained backing store!?!!  Maybe this would be a good time to
> head home for the weekend...

Re backing stores, I thought that value was always ignored nowadays.