Implemented AcceleratedSurface for Windows.

Implemented AcceleratedSurface for Windows.

It allows a D3D9Ex render target texture to be drawn in one process and presented to a Window in another. Presentation is done by a pool of 4 threads so that multiple (up to 4) windows can be presented at full frame rate.

It also deals with acknowleding when it is safe for the producer to render the next frame.

There are some complications with D3D and threading. Even when a device is created with the MULTITHREAD flag, there are limitations to what can be done. Only the thread that creates the device can reset it or destroy it. Therefore each Accelerated surface keeps track of which thread that is. Any thread can present so a simple round robin scheduler assigns presents to the least recently used thread.

It'll be used by this: 
http://codereview.chromium.org/8060045/
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=108169

[nduca, 2011-10-25 19:11:06]

I can haz TRACE_EVENTs peppered through time-consuming parts of this patch?

[apatrick, 2011-10-25 20:03:54]

That would be awesome but ui/surface can't depend on gpu/. I suppose I could
move this to gpu/ though. I was planning on putting it somewhere else
anyway.

On Tue, Oct 25, 2011 at 12:11 PM, <nduca@chromium.org> wrote:

> I can haz TRACE_EVENTs peppered through time-consuming parts of this patch?
>
>
http://codereview.chromium.**org/8395012/<http://codereview.chromium.org/8395...
>

[nduca, 2011-10-25 20:15:14]

trace_event.h is a base/debug thing... does that help?

[apatrick_chromium, 2011-10-26 23:20:57]

On 2011/10/25 20:15:14, nduca wrote:
> trace_event.h is a base/debug thing... does that help?

Done

[apatrick_chromium, 2011-10-27 01:03:27]

+jbauman.

Can you take a look at this? nduca is rather busy.

[jbauman, 2011-10-27 01:26:34]

http://codereview.chromium.org/8395012/diff/3005/ui/gfx/surface/accelerated_s...
File ui/gfx/surface/accelerated_surface_win.cc (right):

http://codereview.chromium.org/8395012/diff/3005/ui/gfx/surface/accelerated_s...
ui/gfx/surface/accelerated_surface_win.cc:186: parameters.Flags =
D3DPRESENTFLAG_LOCKABLE_BACKBUFFER;
Is this necessary? Also, what presentation interval?

http://codereview.chromium.org/8395012/diff/3005/ui/gfx/surface/accelerated_s...
ui/gfx/surface/accelerated_surface_win.cc:333: } while (hr == S_FALSE);
I'm a bit worried about all the extra latency we're adding waiting for the GPU
to finish between gpu process present and stretchrect and between stretchrect
and present. Would it make sense to do this query loop on another dedicated
thread?

[apatrick_chromium, 2011-10-27 17:44:32]

http://codereview.chromium.org/8395012/diff/3005/ui/gfx/surface/accelerated_s...
File ui/gfx/surface/accelerated_surface_win.cc (right):

http://codereview.chromium.org/8395012/diff/3005/ui/gfx/surface/accelerated_s...
ui/gfx/surface/accelerated_surface_win.cc:186: parameters.Flags =
D3DPRESENTFLAG_LOCKABLE_BACKBUFFER;
On 2011/10/27 01:26:35, jbauman wrote:
> Is this necessary? Also, what presentation interval?

I was messing with using LockRect on the back buffer for synchronization instead
of the query and forgot to take this out. Will fix.

http://codereview.chromium.org/8395012/diff/3005/ui/gfx/surface/accelerated_s...
ui/gfx/surface/accelerated_surface_win.cc:333: } while (hr == S_FALSE);
On 2011/10/27 01:26:35, jbauman wrote:
> I'm a bit worried about all the extra latency we're adding waiting for the GPU
> to finish between gpu process present and stretchrect and between stretchrect
> and present. Would it make sense to do this query loop on another dedicated
> thread?

Good idea. I'll try it.

[apatrick_chromium, 2011-10-28 21:54:21]

All done. PTAL.

[jbauman, 2011-10-31 22:50:31]

lgtm

[apatrick_chromium, 2011-11-01 18:02:33]

Thinking about this some more, in the event that a present is requested before a
prior one has been acknowledged, do you think i should create multiple query
objects? At the moment, it has just one and it would wind up reissuing a query
before the previous GetData had returned S_OK. Maybe not a big deal because the
GPU process would be misbehaving in that case anyway.

[Ben Goodger (Google), 2011-11-01 22:38:32]

I don't see an OWNERS file in ui/gfx/surface or ui/gfx. Given that, and the
OWNERS file in src/ui, how did this get committed? I don't see sky or my
LGTM anywhere.

I discovered this because this change broke the Aura build.

-Ben

On Tue, Nov 1, 2011 at 11:02 AM, <apatrick@chromium.org> wrote:

> Thinking about this some more, in the event that a present is requested
> before a
> prior one has been acknowledged, do you think i should create multiple
> query
> objects? At the moment, it has just one and it would wind up reissuing a
> query
> before the previous GetData had returned S_OK. Maybe not a big deal
> because the
> GPU process would be misbehaving in that case anyway.
>
>
http://codereview.chromium.**org/8395012/<http://codereview.chromium.org/8395...
>

[apatrick_chromium, 2011-11-01 22:52:12]

On 2011/11/01 22:38:32, Ben Goodger (Google) wrote:
> I don't see an OWNERS file in ui/gfx/surface or ui/gfx. Given that, and the
> OWNERS file in src/ui, how did this get committed? I don't see sky or my
> LGTM anywhere.
> 
> I discovered this because this change broke the Aura build.
> 
> -Ben
> 
> On Tue, Nov 1, 2011 at 11:02 AM, <mailto:apatrick@chromium.org> wrote:
> 
> > Thinking about this some more, in the event that a present is requested
> > before a
> > prior one has been acknowledged, do you think i should create multiple
> > query
> > objects? At the moment, it has just one and it would wind up reissuing a
> > query
> > before the previous GetData had returned S_OK. Maybe not a big deal
> > because the
> > GPU process would be misbehaving in that case anyway.
> >
> >
>
http://codereview.chromium.**org/8395012/%3Chttp://codereview.chromium.org/83...>
> >

That's strange. I got no presubmit warning about OWNERS. Sorry about that.

[Ben Goodger (Google), 2011-11-01 22:53:30]

No problem. Looks like we didn't have set noparent set. I just fixed it.

I will need to exclude accelerated_surface_win from aura builds.

-Ben

On Tue, Nov 1, 2011 at 3:52 PM, <apatrick@chromium.org> wrote:

> On 2011/11/01 22:38:32, Ben Goodger (Google) wrote:
>
>> I don't see an OWNERS file in ui/gfx/surface or ui/gfx. Given that, and
>> the
>> OWNERS file in src/ui, how did this get committed? I don't see sky or my
>> LGTM anywhere.
>>
>
>  I discovered this because this change broke the Aura build.
>>
>
>  -Ben
>>
>
>  On Tue, Nov 1, 2011 at 11:02 AM, <mailto:apatrick@chromium.org> wrote:
>>
>
>  > Thinking about this some more, in the event that a present is requested
>> > before a
>> > prior one has been acknowledged, do you think i should create multiple
>> > query
>> > objects? At the moment, it has just one and it would wind up reissuing a
>> > query
>> > before the previous GetData had returned S_OK. Maybe not a big deal
>> > because the
>> > GPU process would be misbehaving in that case anyway.
>> >
>> >
>>
>
> http://codereview.chromium.****org/8395012/%3Chttp://coderevi**
> ew.chromium.org/8395012/ <http://codereview.chromium.org/8395012/>>
>
>> >
>>
>
> That's strange. I got no presubmit warning about OWNERS. Sorry about that.
>
>
http://codereview.chromium.**org/8395012/<http://codereview.chromium.org/8395...
>

[apatrick_chromium, 2011-11-01 23:13:30]

That'll work, it's not being used by anything yet. Is it just build problems or
is there something more fundamentally wrong with it?

[Ben Goodger (Google), 2011-11-01 23:59:25]

You're using gfx::NativeWindow, which in USE_AURA is defined to be
aura::Window*, not HWND. USE_AURA can be defined on Windows and Linux.

Aura is a synthetic windowing environment that is contained within a single
toplevel window. There is a single compositor at the root that draws the UI
and web content.

-Ben

On Tue, Nov 1, 2011 at 4:13 PM, <apatrick@chromium.org> wrote:

> That'll work, it's not being used by anything yet. Is it just build
> problems or
> is there something more fundamentally wrong with it?
>
>
http://codereview.chromium.**org/8395012/<http://codereview.chromium.org/8395...
>