<div dir="ltr"><div><div><div><div><div><div><div>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. <br></div>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 thought that it could be a good focus for a GSoC project.<br></div>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<br></div>officially in the master branch or even submitted at all. As far as I can tell the developer isn't directly associated with Wine.<br>On the other hand having conformance tests and benchmarks made would save the developer time and allow his patch<br>to be moved through quicker. But really it just looks interesting so I thought I would bring it up.<br></div><br>If this isn't a possibility, then I could use some help finding operations that I can work on.<br><br></div>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<br></div>time on the proposal. I hope that I can make up for this in the final hours.<br></div>Again, thank you for your assistance.<br><div><div><div><br>[1] <a href="https://comminos.com/posts/2018-02-21-wined3d-profiling.html">https://comminos.com/posts/2018-02-21-wined3d-profiling.html</a><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 10:02 AM, Stefan Dösinger <span dir="ltr"><<a href="mailto:stefandoesinger@gmail.com" target="_blank">stefandoesinger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><br><div><br><blockquote type="cite"><div>Am 26.03.2018 um 06:12 schrieb Kieran Duggan <<a href="mailto:kieranduggan15@gmail.com" target="_blank">kieranduggan15@gmail.com</a>>:</div><br class="m_-5351002302752448856Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div>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<br></div>the AtlAxAttachControl function was intended to free container. I namely came to this conclusion because I couldn't really see how the DestroyWindow<br></div>function would be able to free the container. If DestoyWindow is supposed to be responsible for freeing container, I just wasn't<span class="m_-5351002302752448856Apple-converted-space"> </span><br></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">smart enough to figure it out and will have too look again.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote></div></span>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!<div><br></div><div>Ignore the following if it confuses you. It's some semi-educated guesswork on my part:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></blockquote></div><br></div>