[PATCH v2 5/8] shell32/autocomplete: Send messages directly to the edit control's procedure

Alexandre Julliard julliard at winehq.org
Fri Sep 21 09:33:04 CDT 2018


Gabriel Ivăncescu <gabrielopcode at gmail.com> writes:

> On Fri, Sep 21, 2018 at 4:57 PM, Alexandre Julliard <julliard at winehq.org> wrote:
>> Huw Davies <huw at codeweavers.com> writes:
>>
>>> On Fri, Sep 21, 2018 at 03:38:39PM +0300, Gabriel Ivăncescu wrote:
>>>> On Fri, Sep 21, 2018 at 3:02 PM, Huw Davies <huw at codeweavers.com> wrote:
>>>> >
>>>> > As I hinted at above, unless you can type very much faster than me
>>>> > then I don't consider this much of an issue.
>>>>
>>>> Well it's not much of an issue but it's still a slight improvement for
>>>> the wineserver to have to process less in its queue, and all it needs
>>>> is change a few lines (4 in total) from SendMessage to CallWindowProc.
>>>>
>>>> Are you sure you don't want me to do that?
>>>
>>> Yes.
>>>
>>> It may only be 4 lines, but it's a reasonably fundamental change to
>>> how things work which will require time to review and add to the
>>> possibility of regressions.  So if it's not actually improving
>>> things in a noticable manner then it should stay out.
>>
>> Not to mention that SendMessage doesn't do a wineserver call for the
>> thread-local case, so it's not even improving anything.
>>
>> --
>> Alexandre Julliard
>> julliard at winehq.org
>
> Yeah but it's not the SendMessage that's the wineserver call I'm
> talking about, but the fact that it will go through this subclassed
> window procedure again (it starts at the top), which ends up calling
> GetPropW to get the This pointer just to forward it to the edit
> control. As I see, GetPropW uses a wineserver call.

If it turns out that GetPropW is a bottleneck (very unlikely), it can be
optimized in various ways. Please don't obfuscate the code in an attempt
to make things faster where it doesn't matter.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list