Updating calls to offscreen buffers to use a size of (0,0) when they do not require an actual buffer

Updating calls to offscreen buffers to use a size of (0,0) when they do not require an actual buffer

These updates would enable the surfaceless context extension where available.

BUG=377497
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=273225

[dnicoara, 2014-05-27 13:39:54]

PTAL

This CL is a follow-up to https://codereview.chromium.org/49533003 and trying to
enable the surfaceless extension support as per piman@'s suggestion in comment
#7.

[Ken Russell (switch to Gerrit), 2014-05-27 18:46:59]

LGTM

If there's going to be much more ongoing work in this area, it would be better
to file a bug and reference it from all the CLs.

Is there any possibility of eliminating offscreen surfaces from the command
buffer altogether? In other words, having only (a) contexts which render to a
window and (b) fully offscreen contexts where the client is responsible for
allocating an FBO and color buffer? Perhaps pbuffers would still be necessary on
some platforms, but then the API exposed to the command buffer would be
essentially the surfaceless context API.

https://codereview.chromium.org/293293002/diff/40001/content/common/gpu/gpu_c...
File content/common/gpu/gpu_channel_manager.cc (right):

https://codereview.chromium.org/293293002/diff/40001/content/common/gpu/gpu_c...
content/common/gpu/gpu_channel_manager.cc:300:
gfx::GLSurface::CreateOffscreenGLSurface(gfx::Size());
Does this change work correctly on Mac OS? It looks like the tests passed, but I
thought that Mac OS would also refuse to allocate zero-sized pbuffers -- perhaps
only on older versions of the operating system.

[dnicoara, 2014-05-27 19:19:40]

On 2014/05/27 18:46:59, Ken Russell wrote:
> LGTM
> 
> If there's going to be much more ongoing work in this area, it would be better
> to file a bug and reference it from all the CLs.

There shouldn't be, though, recently a bug was filed to track progress of an
accelerated backend for Ozone (which is where we need this).

> 
> Is there any possibility of eliminating offscreen surfaces from the command
> buffer altogether? In other words, having only (a) contexts which render to a
> window and (b) fully offscreen contexts where the client is responsible for
> allocating an FBO and color buffer? Perhaps pbuffers would still be necessary
on
> some platforms, but then the API exposed to the command buffer would be
> essentially the surfaceless context API.

Hmm, I haven't tried that yet. I'll give it a go and see if it would work.

> 
>
https://codereview.chromium.org/293293002/diff/40001/content/common/gpu/gpu_c...
> File content/common/gpu/gpu_channel_manager.cc (right):
> 
>
https://codereview.chromium.org/293293002/diff/40001/content/common/gpu/gpu_c...
> content/common/gpu/gpu_channel_manager.cc:300:
> gfx::GLSurface::CreateOffscreenGLSurface(gfx::Size());
> Does this change work correctly on Mac OS? It looks like the tests passed, but
I
> thought that Mac OS would also refuse to allocate zero-sized pbuffers --
perhaps
> only on older versions of the operating system.

I do not have a mac to test on, so I was relying on the trybots to make sure my
change did not regress anything. Are there any other bots I should try?

[Ken Russell (switch to Gerrit), 2014-05-27 19:38:51]

On 2014/05/27 19:19:40, dnicoara wrote:
> Hmm, I haven't tried that yet. I'll give it a go and see if it would work.

That will probably end up being a larger change so don't block your work on it.
Would be nice if you or someone currently working on this code investigated that
possibility eventually.

> I do not have a mac to test on, so I was relying on the trybots to make sure
my
> change did not regress anything. Are there any other bots I should try?

No, the mac_gpu tryserver is the main one which will verify end-to-end rendering
on the Mac. Those tryservers are running 10.8 and 10.9. The older OS versions
I'm thinking of are 10.6 and 10.7. There are bots on the Chromium and Blink
waterfalls which test those OS versions so please keep an eye on the waterfalls
when landing this change.

[ccameron, 2014-05-27 19:42:55]

Thanks for the heads-up ... I hadn't heard of the PBuffer issue before.

If you do hit issues, I can help out with testing on a 10.6/7 machine.

[dnicoara, 2014-05-27 19:50:53]

I've filed a bug (crbug.com/377961) to keep track of your suggestion.

To be prudent I'll submit the CL tomorrow morning so I can have plenty of time
to monitor the mac bots.

[dnicoara, 2014-05-28 13:33:58]

The CQ bit was checked by dnicoara@chromium.org

[commit-bot: I haz the power, 2014-05-28 13:34:50]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/dnicoara@chromium.org/293293002/40001

[commit-bot: I haz the power, 2014-05-28 14:41:46]

Change committed as 273225

[Nikita (slow), 2014-05-29 10:16:12]

A revert of this CL has been created in
https://codereview.chromium.org/309463003/ by nkostylev@chromium.org.

The reason for reverting is: This CL broke VMTest on ChromiumOS bot:
http://build.chromium.org/p/chromium.chromiumos/builders/ChromiumOS%20%28x86%...
http://build.chromium.org/p/chromium.chromiumos/builders/ChromiumOS%20%28x86%...

See http://crbug.com/378430.

[dnicoara, 2014-05-29 16:48:48]

PTAL

Added the size workaround for GLX Pbuffer since it was breaking some CrOS bots.

[Ken Russell (switch to Gerrit), 2014-05-29 17:42:08]

LGTM, but I think it would be clearer if you created a new CL instead of
modifying this one.

[dnicoara, 2014-05-29 17:42:42]

On 2014/05/29 17:42:08, Ken Russell wrote:
> LGTM, but I think it would be clearer if you created a new CL instead of
> modifying this one.

OK, will do that then.