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