Modified by: dyek real.com
Date: 9/19/2007
Project: Helix And RealPlayer
Synopsis:
This fix and change in the behavior of playback position
slider
makes the player so much more enjoyable to use than before.
Overview:
This change was checked in a day or two ago; here is the
detailed CN.
The following URL is the check-in that completed the
Superbuffer slider
**GUI**
implementation:
Made Superbuffer widget subclass from GtkWidget:
http://lists.helixcommunity.org/pipe
rmail/player-dev/2007-August/003000.html
This check-in provides much-improved/refined
**behavior**
to Superbuffer slider.
This check-in also implemented ideal seek behavior expressed
in this
CN:
Adding QuickSeek() a.k.a. frame-srubbing support to
hxclientkit
http://lists.helixcommunity.org/piperma
il/player-dev/2007-May/002861.html
FOR END USERS:
>From the end user perspective, this check-in put end
users
(a lot more) in control of the playback.
The playback position slider is now fun to use and disturb
playback
underway very minimally.
NEW SLIDER BEHAVIOR:
1. Buttons On Slider, Frame-scrubbing:
Mouse button-1 and 2 pressed ON slider (thumb.)
This always PAUSE current playback and start
frame-scrubbing
(QuickSeek) mode.
2. Button-2 On Trough, Seek Without Pause:
Mouse button-2 pressed on the trough (not on the slider.)
This never PAUSE current playback and never perform
frame-srubbing (QuickSeek.)
Slider is, nonetheless, under user's control,
by first warping to under the mouse, wherever it happened
to be,
and then being dragged along.
At all times, current playback isn't affected.
When button-2 is released, a Seek (not QuickSeek) is
performed
and the playback "warps" to the timeline
location under the mouse,
all without pausing the playback.
Most of the time, the playback appears continuous with a
few
intermediate frames being shown.
3. Button-3, Precision Seeking:
Mouse button-3 pressed on the slider or the trough
(basically
anywhere.)
Button-3 is typically not used in media player.
With this check-in, button-3 is used to, try-and-error,
position
the slider precisely at a timeline location without
letting the
pointer (mouse) movement affects its precision.
Once button-3 pressed, the slider is pinned to the
location of
the mouse and stays there (ignore motions.)
This can be repeated many times until the ideal timeline
location
is achieved using ESCape and button-3 press again.
As in the case of "Button-2 On Trough", Seek
without pause is
performed on button-3 release, so playback appears to be
continuous.
4. Button-1 On Trough, Complex Seek Or QuickSeek
(Frame-scrubbing):
Mouse button-1 pressed on the trough (not slider.)
Button-1 has the most complex behavior and yet it works as
expected,
transparently.
When button-1 is pressed on the trough, there are two
possible
cases continue from there.
If button-1 is released without pointer (mouse) motion,
Seek without pause is performed, because pausing and
QuickSeek isn't
necessary.
This is difficult to do without a steady hand, so the
above
"Button-2 On Trough" and "Button-3"
cases are dedicated to make
this operation easy.
If pointer motion occurred, playback is (only then)
paused, and
Frame-srubbing (QuickSeek) mode is entered.
Playback continues from the timeline location under the
mouse
when button-1 is released.
If Frame-srubbing mode is always desired, one can choose
to press
button-1 or 2 ON the slider (thumb), which triggers pause
and
enters frame-scrubbing, without even needing pointer
(mouse) motion.
So, button-1 is the best case of all situation where if
one clicks
on trough without moving the mouse, Seek without pause is
performed
to make the playback continues smoothly.
However, once the user starts draging the slider, the
Superbuffer
slider is smart enough to trigger Frame-scrubbing.
It is the best of both worlds.
5. Scrolling With Mouse Wheel, Paging Forward Or Backward:
Scrolling result is not as polished as I hoped, yet.
Scrolling without holding Shift key pages (5x steps)
forward or backward, which translates into Seek Paging
without pause.
Scrolling with Shift key held down steps (small change)
forward or backward, which translates into Seek Stepping
without pause.
I'm thinking scrolling could be changed to perform
TrickPlay
(IHXPlaybackVelocity), but this would result in a UI that
is error
prone when the user has no idea that a speed up in
playback was
caused by a touch on the mouse wheel.
6. HOME And END Keys:
After the Superbuffer Slider is brought into focus
(by pressing a button on trough, while staying still, and
ESCape
it out, for example,) HOME and END keys would seek to the
beginning
and the end of the buffer.
Seeking to the end only makes sense for OnDemand and Live
cases,
because seeking to the end of the timeline/file (as
opposed to the
end of the current buffer) would terminate current
playback.
ESCape:
All mouse actions can be ESCaped out before mouse button is
released,
if one changes mind.
When ESCape is hit (before the mouse button is released,)
existing playback would be restored to where it was when the
mouse button was pressed, if necessary, or the playback
would
continue without being interrupted at all, by the mouse
actions.
This allows one to "play with the slider", to some
extends,
without worrying about interrupted playback.
SEEK RESTRICTION:
This check-in also fixed, what I called, the Seek
Restriction problem,
where slider movement is now confined to the buffered
region.
The new Seek Restriction behavior works well for most
playback, but
it probably should be further extended for OnDemand playback
to jump
to a distance future in the timeline and restart buffering
and
playback from there.
Fixed a bug in HXSuperbufHScale not resetting its state back
to
HX_SUPERB_MODE_BG mode, which is in effect when other
Superbuffer
modes aren't in effect.
This includes restoring slider back to the beginning of the
trough
when the playback stops.
THE HXStatusDisplay's SIMULATED TIMEOUT CALLBACK BUG:
Fixed a bug in HXStatusDisplay where the implementation
simulated
timeout callback without making sure that the timeout is
disabled.
This is the main problem to the earlier
"engine-control-versus-user-control"
problem.
MORE CODE REVIEW DETAILS:
THE PREVIOUS OWNERSHIP CONCEPT:
This "engine-control-versus-user-control" problem
was addressed
in the previous code using the concept of ownership;
in short, on-mouse-button-press, client engine lost control
to
positioning of slider to give the user control over it.
So, the direction of influence is from the slider to the
client
engine.
On-mouse-button-release, the direction of influence reverses
to
give the client engine control over the slider.
The code having the control owns the slider.
THE FEEDBACK CYCLE:
The button-release case is tricky.
At that moment, the timeline shown in the slider and what
had already
happened in the client appeared to be still out of sync.
(Maybe the client was still in the process of seeking
through
intermediate frames leading to the target timeline set in
the slider?)
A polling timeout callback to reflect Helix client's
timeline on the
slider would be premature.
The most straight-forward way of reversing the direction of
influence appeared to cause the slider to be set back toward
the
direction it came from, and that MIGHT have formed a
feedback cycle,
where the new slider value drives the client back toward
where it
came from. (This feedback cycle was there when
HXStatusDisplay
simulated timeout bug wasn't fixed.)
The end result was that user doesn't have full control over
the
slider positioning.
THE USER-WANTS-CONTROL PROTOCOL:
This caused me break the simple reversal of direction of
influence
into a protocol where the Superbuffer slider widget can
announce
control over slider using GTK+ signal and then issuing
either
"reposition" signal for Seek without pause cases,
and
"begin-drag", "drag",
"end-drag" signal sequence for QuickSeek cases.
The release of control over slider is always done with a
delayed
signal to give Helix client the time to catch up in its
playback
timeline. The current delay is set to 1 second.
The delay is "configurable" through an instance
variable.
New GTK+ Signals In HXSuperbufHScale:
(a) "user-control-notify"
Signal user wants (or release) control over slider (thumb)
positioning.
Playback position should cease its influence on the
slider.
(b) "reposition"
Signal time to instruct the client player to Seek to a new
position without pause.
(c) "begin-drag"
Signal time to pause the playback in preparation for
QuickSeek.
(d) "drag"
Signal time to QuickSeek while paused.
This "drag" signal has nothing to do with the:
IPC drag-and-drop
("drag-begin", "drag-motion",
"drag-drop", "drag-end")
signals from GtkWidget.
I perhaps should name the GTK+ signals in Superbuffer more
differently to avoid confusion...
(e) "end-drag"
End of Dragging/QuickSeek; signal time to continue
playback in
client player.
Files Modified:
player/app/gtk/superbufhscale.c
player/app/gtk/superbufhscale.h
player/app/gtk/hxstatuspositionslider.cpp
player/app/gtk/hxstatuspositionslider.h
player/app/gtk/hxstatus.cpp
Image Size and Heap Use impact (Client -Only):
None.
Platforms and Profiles Affected:
Linux
Distribution Libraries Affected:
None.
Distribution library impact and planned action:
None.
Platforms and Profiles Build Verified:
Profile: helix_client_all_define
Platform: Fedora Core 6
Platforms and Profiles Functionality verified:
Profile: helix_client_all_define
Platform: Fedora Core 6
Branch: HEAD
Copyright assignment: I am a RealNetworks employee.
--
Daniel Yek.
_______________________________________________
Player-dev mailing list
Player-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/play
er-dev
|
