Please see my other response about the new interface design.
>From the caller's perspective, it's fair to say that the
only change
affecting them is the async change.
Of course, the underneath change I made is more than that,
but they're
implementation details. The caller doesn't need to know/care
about how we
implement this new async interface.
I have tried to implement the old interface with the new
logic, basically
blocking the Enter/ExitFullScreen call till the internal
scheduled callback
returns. It didn't work out. I don't believe there is a
backwards compatible
fix for this.
There are 2 options available:
1. When calling the old FullScreen interface on Windows, we
return explicit
error code to advise the caller to use this new async
interface. For other
platforms, the old FullScreen interface still work as is
now.
2. Deprecate the old FullScreen and implement this new async
version for all
the platforms, though for non-Window platforms, the
underneath
implementation will be kept the same as the old one. It may
loose some
performance due to the async callbacks. Since FullScreen is
such a dramatic
change in user experience, it's likely neglegible by the
user.
Both require changes in the caller's code. I was thinking
option 1, but I am
fine with either one.
-->Henry
> -----Original Message-----
> From: Greg Wright [mailto:gwright real.com]
> Sent: Monday, November 13, 2006 5:52 PM Ping
> To: Henry Ping
> Cc: 'Milko Boic'; helix-client-devhelixcommunity.org
> Subject: Re: [Helix-client-dev] CR-Client: new
FullScreen
> solution on Windows
>
> Henry Ping wrote:
> >> We can support general full screen attributes
and document
> then for
> >> different platforms:
> >>
> >> HX_RESULT EnterFullScreenExt( HX_WINDOW* pWin,
IHXValue*
> pProperties
> >> );
> >
> > FullScreen support should be a pretty simple &
straight forward
> > interface, I don't understand why we need to make
it more
> complex than
> > the older one. Why the caller needs to know and
specify
> some implementation details?
>
>
> Here are my thoughts, to generate some more
discussion...
>
> I guess my confusion comes from my belief that big
changes
> where not asyncrous in nature. I feel they are the way
we
> re-parent the window, which window we draw to and the
> re-initialization of the graphics system because of
those
> changes. You seem to be saying that the only real
change is
> the addition of an async call. If the async nature of
the
> call is the only real change, then I would agree that
we
> could inherit from the old interface and not provide
any new
> parameters. However, this would also lead me to believe
that
> *any* app we have out there right now could use either
> interface and not have any change in their behavior
(bugs or
> crashes). If this is the case, the we should probably
remove
> the old code for doing full screen and just use the new
code
> that does the new re-parenting and drawing to the new
window.
> Why have both if the applications can't tell the
difference?
> I like the idea that we don't re-parent the normal
window
> when we go to full screen with this new code anyway. If
we
> can remove the old full screen code and just use this
new
> code for both the old and new full screen interfaces,
then I
> think we should. The TLC should not be able to tell the
difference.
>
>
> If it is impossible for us to use the new code for the
old
> full screen interface and still keep backwards
compatibility,
> then I think we have to have a new interface. This
would make
> it obvious that it is different and also take the
opurtinity
> to fill in some holes we have had with the old full
screen
> interface. I think this new interface should allow the
user
> to pass in a window and some options if they care to.
All
> parameters would have defaults so that they don't pass
> anything they don't want to, and the site is as
automatic as
> we can make it. On non desktop systems we have had to
hack in
> preferences and new members to the HXxWindow structure
to
> work around certain full screen problems. Stuff like
rotation
> preferences and scaling/letter-boxing options. It would
be
> nice if the new interface had a way for the TLC to pass
these
> options into the site when it goes full screen. We
perhaps
> could have another new interface that a TLC could use
to add
> and remove IHXValues that has nothing to do with full
screen
> to do the same thing.
>
>
> --greg.
>
>
>
> > -->Henry
> >
> >> -----Original Message-----
> >> From: Milko Boic [mailto:milkoreal.com]
> >> Sent: Monday, November 13, 2006 12:35 PM Ping
> >> To: Greg Wright; Henry Ping
> >> Cc: helix-client-devhelixcommunity.org
> >> Subject: Re: [Helix-client-dev] CR-Client: new
FullScreen
> solution on
> >> Windows
> >>
> >> At 12:15 PM 11/13/2006, Greg Wright wrote:
> >>> Henry Ping wrote:
> >>>> Our current FullScreen solution does
the re-parenting, it
> >> creats a new
> >>>> FullScreen Window and changes the
parent of the TLS(Top
> Level Site)
> >>>> Window to it. We keep blitting the
video to the same TLS
> Window and
> >>>> don't need to reset DirectDraw during
the FullScreen switch.
> >>>> On the other hand, the TLS Window is
created and owned by the
> >>>> application, re-parenting the Window
we don't own can cause
> >> unexpected
> >>>> behavior in the application. We have
observed such problem
> >> with ATL application.
> >>>> The new FullScreen solution removes
the re-parenting, it
> >> creats a new
> >>>> FullScreen Window, it leaves the
parent of the TLS
> Window alone and
> >>>> blits the video directly to the
FullScreen Window. This
> is a much
> >>>> cleaner and self-contained solution.
> >>> On a general note, I think we need to
think about how a
> >> developer would
> >>> decide on which full screen interface to
use, now that we
> >> have 2 of them.
> >>> We are introducing this notion of one
interface doing
> >> re-parenting and
> >>> the other not. This does not follow to how
we generally add
> >> new interfaces.
> >>> We gernerally create a new interface that
can do what the
> >> old one can
> >>> plus the new features, thus, eventually
deprecating the
> old one. I
> >>> think we should add a flag to this new
interface to control
> >>> re-parenting. That way we can tell all
users to use this one
> >> interface only. This also brings up:
> >>> +DECLARE_INTERFACE_(IHXSiteFullScreen2,
IHXSiteFullScreen)
> >>>
> >>> Why do we inherit from IHXSiteFullScreen?
I don't think
> we every use
> >>> the
> >>> TestFullScreen() method of
IHXSiteFullScreen any more, and
> >> possibly the
> >>> IsFullScreen() method as well. I think the
new interface
> should not
> >>> inherit from the old.
> >> I agree.
> >>
> >>
> >>> In addition, I thought we were going to
give the ability for the
> >>> developer to pass in a window that they
created for use
> as the full
> >>> screen window. As with the rest of the
site, we allow both user
> >>> generated and site generated windows. What
do folks think about:
> >>>
> >>> + HX_RESULT EnterFullScreenExt(
HX_WINDOW* pWin, HXBOOL
> >> reparent );
> >>
> >> Re-parenting is a platform specific concept
and we should
> not expose
> >> it in the API.
> >> We can support general full screen attributes
and document
> then for
> >> different platforms:
> >>
> >> HX_RESULT EnterFullScreenExt( HX_WINDOW* pWin,
IHXValue*
> pProperties
> >> );
> >>
> >>
> >>
> >>> +STDMETHODIMP
CHXBaseSite::EnterFullScreenExt() {
> >>> + HX_RESULT ret = HXR_OK;
> >>> +
> >>> + if (m_pParentSite)
> >>> + {
> >>> + return
m_pParentSite->EnterFullScreenExt();
> >>> + }
> >>> +
> >>> + if (m_bInFullScreen &&
m_pFullScreenWatcher)
> >>> + {
> >>> +
m_pFullScreenWatcher->FullScreenEntered(HXR_OK);
> >>> + return HXR_OK;
> >>> + }
> >>> +
> >>> + _TLSLock();
> >>> + ret = _EnterFullScreenExt();
> >>> + _TLSUnlock();
> >>> + return ret;
> >>> +}
> >>>
> >>> This code seems wrong. How can
m_bInFullScreen be set
> before we call
> >>> _EnterFullScreenExt()? It seems we need to
move this code
> >> lower. Same
> >>> goes for ExitFullScreenExt().
> >>>
> >>> Also, there is nothing that says
IHXSiteFullScreenWatcher is
> >> only good
> >>> for the new IHXSiteFullScreen2. It seems
we should call the
> >> new watcher
> >>> methods from the old Enter/Exit
FullScreen() methods as well.
> >>>
> >>> Did you test exiting full screen using
alt-tab, the 'esc'
> >> key and the
> >>> other methods we honor for exiting full
screen?
> >>>
> >>>
> >>> I also think we can make a lot of this
code cross
> platform (none is
> >>> now). Looking forward to when someone has
to port to linux/OS X:
> >>>
> >>> o The window caching and related routines
should be in basesite.
> >>> o same with window size and position.
Those are all generic.
> >>> We could have platform specific
functions (if we don't
> >> already) for
> >>> _GetScreenSize (full screen window size)
> >>> _GetWindowSizePos( window size, window
position)
> >>> we already have GetWindow() and others.
> >>>
> >>> Using these I think we can make the
enter and exit methods more
> >>> cross platform and generic. We can, in
time, then use these to
> >>> clean up the old full screen code as
well. As it sits, we would
> >>> have a bunch of duplicated code in all
platforms for each
> >> FS interface.
> >>> o All the code in
CHXWinSite::_DoEnterFullScreen() seems
> very cross
> >>> platform to me. Same with
CHXWinSite::_ExitFullScreenExt(),
> >>> CHXWinSite::_DoFullScreenSwitch(),
> >> CHXWinSite::FullScreenSwitchCallback().
> >>>
> >>>
> >>>
> >>> I notice you schedule a call back for each
Enter and Exit
> >> FullScreen().
> >>> I take it this is because you need to get
it on the main
> app thread?
> >>> If so, does this mean we support calling
those methods on
> >> non main-app
> >>> threads?
> >>>
> >>>
> >>> Did you try some SMIL clips with
animation/transitions?
> That is the
> >>> best way to test if all the sizes got
updated correctly when
> >> we go to
> >>> full screen
(\gwright6ContentAlphaBlending*.smil). You
> >> can also use
> >>> some of those clips (like
animatetest2.smil to test to make
> >> sure mouse
> >>> clicks (and other window messages) are
getting sent to
> the correct
> >>> sites still (one worry when changing
windows).
> >>>
> >>> In our current ExitFullScreen() code we
have:
> >>>
> >>> // Avoid dead-lock in vidsurf2
> >>> LockBlitters();
> >>> FlushSurfaces();
> >>>
> >>>
> >>> Do you not need to do that with the new
ExitFullScreen()?
> If you are
> >>> not sure, I would add that into your code
as it may be a
> >> hard to repro
> >>> bug when exiting full screen.
> >>>
> >>>
> >>> --greg.
> >>>
> >>>
> >>>
> >>>> Changes:
> >>>> - Added IHXSiteFullScreen2 that
implements this new FullScreen
> >>>> solution, both EnterFullScreen() and
ExitFullScreen() are
> >> async methods.
> >>>> - Added IHXSiteFullScreenWatcher that
receives the status of
> >>>> FullScreen async calls.
> >>>> - When EnterFullScreenExt is called,
we creates the new
> FullScreen
> >>>> Window, caches the native TLS Window
created by the application,
> >>>> detach & attach to the new
FullScreen Window and schedule a
> >> callback to reset the DirectDraw.
> >>>> - When ExitFullScreenExt is called, we
detach & attach to
> >> the native
> >>>> TLS Window cached earlier, schedule a
callback to reset the
> >> DirectDraw
> >>>> and destroy the FullScreen Window
afterwards.
> >>>> Files Modified:
> >>>> common/include/hxiids.h
> >>>> common/include/hxwin.h
> >>>> video/sitelib/basesite.cpp
> >>>> video/sitelib/pub/basesite.h
> >>>>
video/sitelib/platform/win/windraw2.cpp
> >>>> video/sitelib/platform/win/winsite.cpp
> >>>>
video/sitelib/pub/platform/win/winsite.h
> >>>>
video/sitelib/pub/platform/mac/macsite.h
> >>>>
video/sitelib/pub/platform/unix/unixsite.h
> >>>> Image Size and Heap Use impact (Client
-Only):
> >>>> insignificant
> >>>> Platforms and Profiles Affected:
> >>>> Windows only
> >>>> Distribution Libraries Affected:
> >>>> none
> >>>> Distribution library impact and
planned action:
> >>>> n/a
> >>>> Platforms and Profiles Build Verified:
> >>>> win32-i386-vc7,
helix-client-all-defines Platforms and Profiles
> >>>> Functionality verified:
> >>>> win32
> >>>> -->Henry
> >>>>
> >>>>
------------------------------------------------------------
> >> ----------
> >>>> --
_______________________________________________
> >>>> Helix-client-dev mailing list
> >>>> Helix-client-devhelixcommunity.org
> >>>> http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
> >>>
_______________________________________________
> >>> Helix-client-dev mailing list
> >>> Helix-client-devhelixcommunity.org
> >>> http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
> >>
> >
> >
_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
|