|
List Info
Thread: CR: Fix VS2 frame updates while paused.
|
|
| CR: Fix VS2 frame updates while paused. |
|
2006-07-13 22:28:47 |
Project
=======
Synopsis
========
Fix internal bug
"Bug 170450: The player does not update video while
seeking when paused."
Here are the repro steps:
o Play any RV clip.
o Pause the player.
o Click in the seek bar
Notice that the image does not update with the seek until
you mouse over the video causing a screen refresh. It should
always show you the frame where you seeked to.
This only happens with VS2. VS1 and GDI blt's work fine.
This bug keeps the new frame scubbing(Quick seek) feature
from working
without dropping out of VS2 mode.
Fix
===
I added a call to Present( ..., ..., HX_MODE_TIMED, ...,
...) instead
of calling ForceRefresh(). Force refresh does not work
because it
always returns early because we are in VS2 mode. I believe,
but have
not tried, that this has been broken forever. You don't
notice this
bug while playing because after this immediate frame fails
there is
always a new timed frame right behind it. See the comments
below for
more details.
Also, I am open for better or other fixes. There is going to
be a bit
of a lag for just the first frames with this fix, but, I
think it is
a lot safer then trying to tweak VS2 once again. I have
tried both
this new timed Present() call and the immediate Present()
calls and
don't really see any noticeable difference in how frame
scrubbing
feels to the user.
I also tested with all my video transition alphablending
SMIL files
and did not run into any artifacts or deadlocks.
Files Modified
==============
datatype/common/vidrend/vidrend.cpp
Branch(s)
=========
HEAD and 150Cay (diffs to 150Cay).
I think the code itself is better to look at then the
diffs, so I put it inline here. The real diffs are at the
end.
//XXXgfw If we do it the original way
that is in the
//comments below then we never see
frames while seeking when
//paused. Since we are worried only
about taking the TLS
//mutex and the dead lock that may
result, I will instead
//use HX_MODE_TIMED Present() calls.
Only the
//HX_MODE_IMMEDIATE Present() calls
take the mutex. This may
//result in a frame showing up a bit
later (next VBlank
//interval or so) but this is only for
the first frame; we
//are inside a if() block for first
frames only. Since VS2
//problems, especially dead lock
problems, are notoriously
//hard to find and fix, I will leave
the below code in place
//until we(QA) are certain that the new
code works. If we
//ever turn the commented code below
back on, frame scrubbing
//(quick seek) under VS2 will stop
working again (you won't
//see any of the seek frames).
// // Unless this is a system event we
are not under the protection of the
// // top level site mutex and present
immediate will acquire TLS mutex.
// // We must avoid deadlock with
HandleEvent by relinquishing
// // VS mutex and forcing refresh.
// m_bPresentInProgress = FALSE;
// // The buffer was not displayed in
this update
// m_bVSBufferUndisplayed = TRUE;
// ForceRefresh();
// // Since we have handed off the
update by setting
// // m_bVSBufferUndisplayed (and
envoking ForceRefresh()),
// // proceed outside of new frame
handling mode since subsequent
// // update will take into account the
undisplayed new frame.
// bNewFrameBlt = FALSE;
// // Abort any further updates for
multiple site users since
// // ForceRefresh will take care of all
of them
// retVal = HXR_ABORT;
retVal = pVideoSurface2->Present(
&videoMemoryInfo,
m_pActiveVideoPacket->m_ulTime,
HX_MODE_TIMED,
&destRect,
&sorcRect);
=========== Diffs against 150Cay ==============
Index: vidrend.cpp
============================================================
=======
RCS file: /cvsroot/datatype/common/vidrend/vidrend.cpp,v
retrieving revision 1.54.2.13
diff -w -u -d -r1.54.2.13 vidrend.cpp
--- vidrend.cpp 7 Jul 2006 19:35:11 -0000 1.54.2.13
+++ vidrend.cpp 13 Jul 2006 22:18:00 -0000
 -4525,26
+4525,45
}
else
{
- // Unless this is a system event we are
not under the protection of the
- // top level site mutex and present
immediate will acquire TLS mutex.
- // We must avoid deadlock with
HandleEvent by relinquishing
- // VS mutex and forcing refresh.
- m_bPresentInProgress = FALSE;
-
- // The buffer was not displayed in this
update
- m_bVSBufferUndisplayed = TRUE;
+ //XXXgfw If we do it the original way
that is in the
+ //comments below then we never see
frames while seeking when
+ //paused. Since we are worried only
about taking the TLS
+ //mutex and the dead lock that may
result, I will instead
+ //use HX_MODE_TIMED Present() calls.
Only the
+ //HX_MODE_IMMEDIATE Present() calls
take the mutex. This may
+ //result in a frame showing up a bit
later (next VBlank
+ //interval or so) but this is only for
the first frame; we
+ //are inside a if() block for first
frames only. Since VS2
+ //problems, especially dead lock
problems, are notoriously
+ //hard to find and fix, I will leave
the below code in place
+ //until we(QA) are certain that the new
code works. If we
+ //ever turn the commented code below
back on, frame scrubbing
+ //(quick seek) under VS2 will stop
working again (you won't
+ //see any of the seek frames.
- ForceRefresh();
+// // Unless this is a system event we
are not under the protection of the
+// // top level site mutex and present
immediate will acquire TLS mutex.
+// // We must avoid deadlock with
HandleEvent by relinquishing
+// // VS mutex and forcing refresh.
+// m_bPresentInProgress = FALSE;
+// // The buffer was not displayed in
this update
+// m_bVSBufferUndisplayed = TRUE;
+// ForceRefresh();
+// // Since we have handed off the
update by setting
+// // m_bVSBufferUndisplayed (and
envoking ForceRefresh()),
+// // proceed outside of new frame
handling mode since subsequent
+// // update will take into account the
undisplayed new frame.
+// bNewFrameBlt = FALSE;
+// // Abort any further updates for
multiple site users since
+// // ForceRefresh will take care of
all of them
+// retVal = HXR_ABORT;
- // Since we have handed off the update
by setting
- // m_bVSBufferUndisplayed (and envoking
ForceRefresh()),
- // proceed outside of new frame
handling mode since subsequent
- // update will take into account the
undisplayed new frame.
- bNewFrameBlt = FALSE;
+ retVal = pVideoSurface2->Present(
&videoMemoryInfo,
+
m_pActiveVideoPacket->m_ulTime,
+
HX_MODE_TIMED,
+
&destRect,
+
&sorcRect);
- // Abort any further updates for
multiple site users since
- // ForceRefresh will take care of all
of them
- retVal = HXR_ABORT;
}
}
else
_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev
|
|
| CN: Fix VS2 frame updates while paused. |
|
2006-07-18 22:50:01 |
I wanted to get this checked in, with the original code in
place,
so that testing can begin on frame scrubbing. I still need a
CR for this and will back it out, make changes or whatever
is
needed depending on CR feedback.
Now in 150Cay and HEAD.
--greg.
Greg Wright wrote:
> Project
> =======
>
> Synopsis
> ========
> Fix internal bug
>
> "Bug 170450: The player does not update video
while seeking when paused."
>
> Here are the repro steps:
>
> o Play any RV clip.
> o Pause the player.
> o Click in the seek bar
>
> Notice that the image does not update with the seek
until
> you mouse over the video causing a screen refresh. It
should
> always show you the frame where you seeked to.
>
> This only happens with VS2. VS1 and GDI blt's work
fine.
>
> This bug keeps the new frame scubbing(Quick seek)
feature from working
> without dropping out of VS2 mode.
>
> Fix
> ===
>
> I added a call to Present( ..., ..., HX_MODE_TIMED,
..., ...) instead
> of calling ForceRefresh(). Force refresh does not work
because it
> always returns early because we are in VS2 mode. I
believe, but have
> not tried, that this has been broken forever. You
don't notice this
> bug while playing because after this immediate frame
fails there is
> always a new timed frame right behind it. See the
comments below for
> more details.
>
> Also, I am open for better or other fixes. There is
going to be a bit
> of a lag for just the first frames with this fix, but,
I think it is
> a lot safer then trying to tweak VS2 once again. I have
tried both
> this new timed Present() call and the immediate
Present() calls and
> don't really see any noticeable difference in how
frame scrubbing
> feels to the user.
>
> I also tested with all my video transition
alphablending SMIL files
> and did not run into any artifacts or deadlocks.
>
> Files Modified
> ==============
> datatype/common/vidrend/vidrend.cpp
>
> Branch(s)
> =========
> HEAD and 150Cay (diffs to 150Cay).
>
>
> I think the code itself is better to look at then the
> diffs, so I put it inline here. The real diffs are at
the
> end.
>
> //XXXgfw If we do it the original
way that is in the
> //comments below then we never see
frames while
> seeking when
> //paused. Since we are worried only
about taking the
> TLS
> //mutex and the dead lock that may
result, I will
> instead
> //use HX_MODE_TIMED Present()
calls. Only the
> //HX_MODE_IMMEDIATE Present() calls
take the mutex.
> This may
> //result in a frame showing up a
bit later (next VBlank
> //interval or so) but this is only
for the first
> frame; we
> //are inside a if() block for first
frames only.
> Since VS2
> //problems, especially dead lock
problems, are
> notoriously
> //hard to find and fix, I will
leave the below code
> in place
> //until we(QA) are certain that the
new code works.
> If we
> //ever turn the commented code
below back on, frame
> scrubbing
> //(quick seek) under VS2 will stop
working again
> (you won't
> //see any of the seek frames).
>
> // // Unless this is a system event
we are not under
> the protection of the
> // // top level site mutex and
present immediate
> will acquire TLS mutex.
> // // We must avoid deadlock with
HandleEvent by
> relinquishing
> // // VS mutex and forcing refresh.
> // m_bPresentInProgress = FALSE;
> // // The buffer was not displayed
in this update
> // m_bVSBufferUndisplayed = TRUE;
> // ForceRefresh();
> // // Since we have handed off the
update by setting
> // // m_bVSBufferUndisplayed (and
envoking
> ForceRefresh()),
> // // proceed outside of new frame
handling mode
> since subsequent
> // // update will take into account
the undisplayed
> new frame.
> // bNewFrameBlt = FALSE;
> // // Abort any further updates for
multiple site
> users since
> // // ForceRefresh will take care
of all of them
> // retVal = HXR_ABORT;
>
> retVal =
pVideoSurface2->Present( &videoMemoryInfo,
>
> m_pActiveVideoPacket->m_ulTime,
>
HX_MODE_TIMED,
>
&destRect,
>
&sorcRect);
>
>
>
>
>
>
>
>
> =========== Diffs against 150Cay ==============
>
> Index: vidrend.cpp
>
============================================================
=======
> RCS file:
/cvsroot/datatype/common/vidrend/vidrend.cpp,v
> retrieving revision 1.54.2.13
> diff -w -u -d -r1.54.2.13 vidrend.cpp
> --- vidrend.cpp 7 Jul 2006 19:35:11 -0000
1.54.2.13
> +++ vidrend.cpp 13 Jul 2006 22:18:00 -0000
> -4525,26 +4525,45
> }
> else
> {
> - // Unless this is a system event
we are not under
> the protection of the
> - // top level site mutex and
present immediate will
> acquire TLS mutex.
> - // We must avoid deadlock with
HandleEvent by
> relinquishing
> - // VS mutex and forcing refresh.
> - m_bPresentInProgress = FALSE;
> -
> - // The buffer was not displayed in
this update
> - m_bVSBufferUndisplayed = TRUE;
> + //XXXgfw If we do it the original
way that is in the
> + //comments below then we never see
frames while
> seeking when
> + //paused. Since we are worried
only about taking
> the TLS
> + //mutex and the dead lock that may
result, I will
> instead
> + //use HX_MODE_TIMED Present()
calls. Only the
> + //HX_MODE_IMMEDIATE Present()
calls take the mutex.
> This may
> + //result in a frame showing up a
bit later (next
> VBlank
> + //interval or so) but this is only
for the first
> frame; we
> + //are inside a if() block for
first frames only.
> Since VS2
> + //problems, especially dead lock
problems, are
> notoriously
> + //hard to find and fix, I will
leave the below code
> in place
> + //until we(QA) are certain that
the new code works.
> If we
> + //ever turn the commented code
below back on, frame
> scrubbing
> + //(quick seek) under VS2 will stop
working again
> (you won't
> + //see any of the seek frames.
>
> - ForceRefresh();
> +// // Unless this is a system
event we are not
> under the protection of the
> +// // top level site mutex and
present immediate
> will acquire TLS mutex.
> +// // We must avoid deadlock with
HandleEvent by
> relinquishing
> +// // VS mutex and forcing
refresh.
> +// m_bPresentInProgress = FALSE;
> +// // The buffer was not displayed
in this update
> +// m_bVSBufferUndisplayed = TRUE;
> +// ForceRefresh();
> +// // Since we have handed off the
update by setting
> +// // m_bVSBufferUndisplayed (and
envoking
> ForceRefresh()),
> +// // proceed outside of new frame
handling mode
> since subsequent
> +// // update will take into
account the undisplayed
> new frame.
> +// bNewFrameBlt = FALSE;
> +// // Abort any further updates
for multiple site
> users since
> +// // ForceRefresh will take care
of all of them
> +// retVal = HXR_ABORT;
>
> - // Since we have handed off the
update by setting
> - // m_bVSBufferUndisplayed (and
envoking
> ForceRefresh()),
> - // proceed outside of new frame
handling mode since
> subsequent
> - // update will take into account
the undisplayed
> new frame.
> - bNewFrameBlt = FALSE;
> + retVal =
pVideoSurface2->Present( &videoMemoryInfo,
> +
> m_pActiveVideoPacket->m_ulTime,
> +
HX_MODE_TIMED,
> +
&destRect,
> +
&sorcRect);
>
> - // Abort any further updates for
multiple site
> users since
> - // ForceRefresh will take care of
all of them
> - retVal = HXR_ABORT;
> }
> }
> else
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev
>
_______________________________________________
Datatype-dev mailing list
Datatype-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/da
tatype-dev
|
|
[1-2]
|
|