Re: AU views and offset with composite windows
Re: AU views and offset with composite windows
- Subject: Re: AU views and offset with composite windows
- From: "B.J. Buchalter" <email@hidden>
- Date: Mon, 11 Sep 2006 17:25:02 -0400
- Thread-topic: AU views and offset with composite windows
Oh - I thought it was intentional. It looked intentional.
It was with AU hosting that I discovered the problem.
The issue is starts on line 147 of AUCarbonViewBase.cpp (in
AUCarbonViewBase::CreateCarbonView):
if (IsCompositWindow()) {
verify_noerr(::HIViewAddSubview(inParentControl, mCarbonPane));
mXOffset = 0;
mYOffset = 0;
}
else {
verify_noerr(::EmbedControl(mCarbonPane, inParentControl));
mXOffset = inLocation.x;
mYOffset = inLocation.y;
}
This says that if the hosting window is a Compositing window, reset the
mXOffset and mYOffset to zero.
Then when the plug-in's code comes along and tries to use those member
variables, they don't have the right values.
I think the thing is, if you are actually using HIView in your plug,
everything is hunky-dory.
But if you are not using HIView, this base-class code blows away the only
info you have to know where to draw...
Now, our code is not using HIView, but if we preserve the offsets, it does
work properly in composited windows (even though our UI is not composited).
If you want, I can write up a bug about it, but I suspect that it is
something that each developer will have to evaluate on a plug-by-plug basis
to determine the proper way of handling it for their own code...
> AUHosting has
> been (for quite some time now) doing a composited window with a non-
> zero offset for the plugin views as its default behaviour, and to my
> knowledge the generic carbon view we shipped in Tiger works correctly
> there. AULab also has a preference, on by default, to use composited
> windows when hosting carbon views.
I suspect that it works because the generic carbon view uses HIView...
BR,
B.J. Buchalter
Metric Halo
5 Donovan Drive
Hopewell Junction, NY 12533 USA
tel +1 845 223-6112
fax +1 603 250-2451
On 9/11/06 4:05 PM, "William Stewart" <email@hidden> wrote:
> Ah - this is incorrect (or at least unintentional). AUHosting has
> been (for quite some time now) doing a composited window with a non-
> zero offset for the plugin views as its default behaviour, and to my
> knowledge the generic carbon view we shipped in Tiger works correctly
> there. AULab also has a preference, on by default, to use composited
> windows when hosting carbon views.
>
> There is also code added to these classes to make this work (and you
> get a scrollable view for virtually free as an added bonus!). So, if
> you can send us a bug describing where that problem is we'll be happy
> to fix this.
>
> To the general point - yes, we'd consider this a bug and would like
> the AU's concerned to fix their view code.
>
> Bill
>
> On 11/09/2006, at 12:46 PM, B.J. Buchalter wrote:
>
>>
>>
>>
>> On 9/11/06 3:27 PM, "Sebastien Beaulieu" <email@hidden> wrote:
>>
>>> Hi all,
>>>
>>> I'm always getting reports that some plug-ins UI are not showed
>>> correctly when running on the x86 version of my host. So far,
>>> every time I have investigated, the problem lies into the plug-in
>>> UI code not being able to deal with both an offset and a composite
>>> window. If I remove the composite flag, the plugin behaves as
>>> expected.
>>>
>>> Am I wrong expecting that to work for all AUs under x86 ?
>>
>> This is something that is in the base class of the SDK (AUViewBase)
>> that
>> makes it ignore the offset if the hosting window is composited. I'm
>> not sure
>> why the CA team did that as it seems to cause problems that don't
>> need to be
>> there. On our Aus we simply changed the SDK to do the right thing
>> (at least
>> for our UI code). But if a PI manufacturer has not done this than the
>> combination of composited window and offset will not work (by
>> design). So,
>> yeah -- this is probably going to be a problem; but I would say
>> that it is a
>> bug in the affected plugs -- they should be testing with a host that
>> compostites and offsets (one of the apple test tools does this) and
>> have
>> found the required change to the base classes...
>>
>> BR,
>>
>> B.J. Buchalter
>>
>> Metric Halo
>> 5 Donovan Drive
>> Hopewell Junction, NY 12533 USA
>> tel +1 845 223-6112
>> fax +1 603 250-2451
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Coreaudio-api mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden