CR/CN-Client: Implementing Superbuffer Preference dialog options.

Modified by: dyekreal.com
Date: 12/26/2007
Project: RealPlayer

Synopsis: 
(A) Created player Preference dialog box options to: 
1. enable/disable Superbuffer/PerfectPlay and
2. set Superbuffer size.

(B) Created a code structure to: 
1. specify Helix Preferences default values and
2. trigger associated actions for Preference during player
startup.

Overview: 


(A)
Implemented prefs_combobox_read() and prefs_combobox_write()

Preference dialog box functions to handle Combo Box read and
write
generically with callbacks to: 
convert Combo box index to values and back.

This facility avoid the need to duplicate read and write
code 
for every Combobox in the dialog box.

prefs_combobox_write() also features the write-notification
support
to "enable Helix Preference changes to trigger
actions."
(In fancy terms.)

This is used to interface with hxrecordengine version of the

Superbuffer, which uses function calls, instead of
Preferences to 
enable/disable Superbuffer.

Superbuffer size choices in Preference dialog box are:
5 min
10 min
30 min
1 hr
2 hr
3 hr
6 hr
12 hr

It is worth noting that other values is possible (only) by
editing
realplayerrc file directly.

(B)
Due to the increased need for the player to specify default

Preferences, two functions are created:

1. hxwindow_create_default_preferences():
This is where default Preference values can be written 
(before loading Preferences from file.)

2. hxwindow_execute_preferences_actions():
This is where loaded (player-specific, passive) Preferences
map to 
function calls on Helix Client that was created after #1
above.




This change also included: 
1. a fix for some memory leaks using hx_entry_free() calls.

2. a more convenient ReadPreference() implementation. 
The former implementation requires calls be made twice,
consecutively,
first to get the buffer size only and then get the
Preference value.
That is a weird behavior to me.
Now, as long as the buffer size is adequate, it gets the
value in 
one step.


(C)
MISCELLANEOUS:
Besides what was committed, I tried several other
implementations. 
The reasons for choosing the above implementation over these

are given here.

1. My first implementation was to revert the change that
hxclientengine
made, so that it is enabling and disabling Live and OnDemand

Superbuffer based on their Preferences, just like for
Windows.
This is easiest to implement because existing generic
functions can be 
used to read and write between Preference dialog box and 
Helix Preference. 

And there is no synchronization issue about when Superbuffer
can be 
enabled or disabled -- Preferences are checked only in 
RecordService's OpenSession() at the beginning of playback.

After figuring out the rational behind the change of
behavior
to deviate from Windows -- simplifying enabling and
disabling of 
Superbuffer and completely unload hxrecordengine when
disabled --
and to prevent "disruptive changes in #ifdef
PLATFORMS", 
this approach is considered not good.

2. To continue to use one (new) Helix Preference to enable
and disable
Superbuffer but allows hxrecordengine to be unloaded, I
thought of
changing hxclientkit to check a Preference at specific
points to load
and unload hxrecordengine.
I still like this approach as much Helix functionalities are
configured
through Preferences.
I didn't implement this as it is "disruptive" to
other platforms using
hxclientkit.

3. Implement Helix Preference change notification through
GObject's 
Properties in HXPlayer/GTK+ widget level.
What is nice about this approach is that the function calls
to 
enable/disable hxrecordengine are hidden away at the
HXPlayer level.

The application level will still use the existing generic
functions
to interface with new Preference dialog box elements.

This approach causes problems in non-uniform interfaces for
different
Preferences as some are set using g_object_set() and others
using
ReadPreference() and in synchronizing GObject Properties and

Helix Preference.

Same as the final chosen approach, this approach raises the
question
of when it is safe to call EnableSuperBuffer(, FALSE) to
unload 
hxrecordengine.
It appears that reference counting should have taken cared
of the
issue of not unloading in the middle of playing back.

The biggest problem with this approach is that multiple 
HXPlayer objects could exist at the same time.



Files Modified:
player/app/gtk/prefsdialog.cpp
player/app/gtk/mainapp.cpp - Fix memory leak and enable
Superbuffer at startup.
player/common/gtk/hxplayer.cpp

player/common/gtk/hxgprefs.cpp  - Replace ReadPreference()
with an 
    easier-to-use implementation.

player/app/gtk/res/preferences.glade
player/app/gtk/preferences_interface.c



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