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: William Stewart <email@hidden>
- Date: Mon, 11 Sep 2006 14:42:42 -0700
On 11/09/2006, at 2:25 PM, B.J. Buchalter wrote:
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.
Yes - because when you draw into an HIView, it is the view that is
offset, not your coordinates
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.
Yes - mixing the two would require alot of extra massaging, and one
that the base class doesn't directly support.
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...
Yes - I doubt we'd consider this a bug - rather an enchancement that
we'd probably not consider doing. The general advise for some time
from the HI guys has been for people to move over to using HIViews
(which is in large part what guided the decisions we made)
Thanks
Bill
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:
40apple.com
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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