Student preparing for GSoC

[Kieran Duggan]

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>
wrote:

> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20180327/acc2c036/attachment-0001.html>