Student preparing for GSoC

[Austin English]

On Mon, Mar 26, 2018 at 11:35 PM, Kieran Duggan
<kieranduggan15 at gmail.com> wrote:
> So I took another look at the ideas list and I thought that writing micro
> benchmarks for the D3D components would be about my speed and also fit into
> my interests.
> My only issue is that I am not sure which operations to test.
>
> While I was looking for inspiration I came across this project[1] and
> thought that it could be a good focus for a GSoC project.
> That is, specifically writing micro benchmarks to measure the improvements
> of components effected by changes in wine-pba. I'm very uncertain about this
> however because it isn't
> officially in the master branch or even submitted at all. As far as I can
> tell the developer isn't directly associated with Wine.
> On the other hand having conformance tests and benchmarks made would save
> the developer time and allow his patch
> to be moved through quicker. But really it just looks interesting so I
> thought I would bring it up.
>
> If this isn't a possibility, then I could use some help finding operations
> that I can work on.
>
> I know this is very close to the deadline, so I apologize for my poor
> timing. I underestimated how long it would take me to submit a patch and
> ended up investing not enough
> time on the proposal. I hope that I can make up for this in the final hours.
> Again, thank you for your assistance.
>
> [1] https://comminos.com/posts/2018-02-21-wined3d-profiling.html
>
> On Mon, Mar 26, 2018 at 10:02 AM, Stefan Dösinger
> <stefandoesinger at gmail.com> wrote:
>>
>>
>>
>> Am 26.03.2018 um 06:12 schrieb Kieran Duggan <kieranduggan15 at gmail.com>:
>>
>> The hard part of this for me was figuring out who was responsible for
>> freeing container. After some time I came to the conclusion that the caller
>> of
>> the AtlAxAttachControl function was intended to free container. I namely
>> came to this conclusion because I couldn't really see how the DestroyWindow
>> function would be able to free the container. If DestoyWindow is supposed
>> to be responsible for freeing container, I just wasn't
>> smart enough to figure it out and will have too look again.
>>
>> As far as I can tell (and I haven't touched the atl code myself before)
>> your conclusion is correct. AtlAxAttachControl creates the container object
>> and returns the interface, so the caller is responsible for eventually
>> destroying it. I would say submit your patch :-) . And don't forget to
>> submit your gsoc proposal in time on the google website!
>>
>> Ignore the following if it confuses you. It's some semi-educated guesswork
>> on my part:
>>
>> DestroyWindow doesn't know anything about COM or atl, so the DestroyWindow
>> implementation is certainly not the right place. However, one thing is
>> theoretically possible: DestroyWindow will send WM_DESTROY to the window
>> callback procedure, which could in theory be responsible for releasing the
>> container. AtlAxAttachControl appears to overwrite the wndproc (in
>> IOCS_Attach). IOCS_Detach might be a candidate for releasing the container,
>> it is called on WM_DESTROY.
>>
>> However, I think this is unlikely because AtlAxAttachControl returns the
>> interface to the caller. And convention says that the caller that receives
>> an interface must release it once it is done. Of course Microsoft screws up
>> its own COM rules a lot.
>>
>> You can try to do to find out by looking at how Windows behaves when it is
>> running this test: You can read the reference count by calling AddRef()
>> followed by Release(). (there is a function get_refcount in numerous places,
>> e.g. dlls/ddraw/tests). After AtlAxAttachControl I'd expect it to be 1. If
>> it is still 1 after DestroyWindow(), the window callbacks should leave the
>> refcount alone. If trying to call AddRef() after DestroyWindow crashes, or
>> the refcount is zero, something in the window procedure released the
>> container.

I don't think making a project about a wine fork (that's not
upstreaming it) is a useful use of GSOC resources.

-- 
-Austin
GPG: 267B CC1F 053F 0749 (expires 2021/02/18)