Student preparing for GSoC
kieranduggan15 at gmail.com
Mon Mar 26 23:48:18 CDT 2018
That's what I figured. I thought I would try anyway.
On Tue, Mar 27, 2018, 12:45 AM Austin English <austinenglish at gmail.com>
> 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
> > 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 and
> > thought that it could be a good focus for a GSoC project.
> > That is, specifically writing micro benchmarks to measure the
> > of components effected by changes in wine-pba. I'm very uncertain about
> > 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
> > 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
> > Again, thank you for your assistance.
> >  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
> >> of
> >> the AtlAxAttachControl function was intended to free container. I namely
> >> came to this conclusion because I couldn't really see how the
> >> function would be able to free the container. If DestoyWindow is
> >> 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
> >> 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
> >> on my part:
> >> DestroyWindow doesn't know anything about COM or atl, so the
> >> 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
> >> container. AtlAxAttachControl appears to overwrite the wndproc (in
> >> IOCS_Attach). IOCS_Detach might be a candidate for releasing the
> >> 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
> >> 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
> >> running this test: You can read the reference count by calling AddRef()
> >> followed by Release(). (there is a function get_refcount in numerous
> >> e.g. dlls/ddraw/tests). After AtlAxAttachControl I'd expect it to be 1.
> >> it is still 1 after DestroyWindow(), the window callbacks should leave
> >> refcount alone. If trying to call AddRef() after DestroyWindow crashes,
> >> 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.
> GPG: 267B CC1F 053F 0749 (expires 2021/02/18)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wine-devel