[Lxdream-dev] OSD work in progress

[Nathan Keynes]

On Fri, Jul 10, 2009 at 1:15 PM, Jon Ring <jonnyring at gmail.com> wrote:

> I have attached a patch that demonstrates the OSD functionality at this
> point.  Here are some things to note and/or discuss, in no particular
> order:
>
> 1.  I used the FTGL library to do the drawing.  It is cross platform and
> should be lightweight enough.
>

Hmm. I am unable to install this library on debian as something is wrong
with the dependencies (it tries to remove the X server if I install it...),
and I can't build it manually on this machine as I have no GL/glu.h (which I
also can't install for the same reason). On mac I can install 2.1.2, which
appears to have different type names to whichever version you used (ie it
doesn't have FTGLfont) and osd_ftgl.c won't compile.

So... I think we can't have it as a mandatory dependency under the
circumstances - either we bundle FTGL (or some subset) into the source tree
and integrate it fully (which admittedly doesn't help with my missing glu.h
problem), or we have a fallback to a non-ftgl font rendering, or we drop it
and just do the rendering ourselves. Which option probably depends on how
good the FTGL font quality is, and whether you want to use any of it's
fancier options, but I'd be happy with a fallback.

If you check an old revision (was in lxdream_0_8, not sure when I took it
out), there was actually some font code once upon a time, spread across
video_glx.c and render.c. I'm not saying it was particularly pretty, but
it's fairly simple:

int video_glx_load_font( const gchar *font_name )
{
    int lists;
    XFontStruct *font = XLoadQueryFont(video_x11_display, font_name );
    if (font == NULL)
        return -1;

    lists = glGenLists(96);
    glXUseXFont(font->fid, 32, 96, lists);
    XFreeFont(video_x11_display, font);
    return lists;
}

int pvr2_render_font_list = -1;
int glPrintf( int x, int y, const char *fmt, ... )
{
    va_list ap;     /* our argument pointer */
    char buf[256];
    int len;
    if (fmt == NULL)    /* if there is no string to draw do nothing */
        return 0;
    va_start(ap, fmt);
    len = vsnprintf(buf, sizeof(buf), fmt, ap);
    va_end(ap);


    glPushAttrib(GL_LIST_BIT);
    glDisable( GL_DEPTH_TEST );
    glDisable( GL_BLEND );
    glDisable( GL_TEXTURE_2D );
    glDisable( GL_ALPHA_TEST );
    glDisable( GL_CULL_FACE );
    glListBase(pvr2_render_font_list - 32);
    glColor3f( 1.0, 1.0, 1.0 );
    glRasterPos2i( x, y );
    glCallLists(len, GL_UNSIGNED_BYTE, buf);
    glPopAttrib();

    return len;
}

On the downside it doesn't give you the font boxes, but I guess you could
use the X methods for that.


> 2.  I am currently using fontconfig to get the path to a font.  I'm pretty
> sure it's X-specific, so that part won't work on OSX.  We'd need to find a
> different way to get the path to an appropriate font there.  OSX, I
> believe,
> comes with a default set of fonts that will always be there, so perhaps
> getting a path to a well-known font won't be so bad on that platform.
> Possible alternatives to trying to automatically find a font (on any
> platform) are making the user pick a font (not the best idea in the world)
> and including a font with lxdream.  Including a font also has the advantage
> of being guaranteed to look the same on every platform.
>

Yeah no biggie, this bit will probably be platform-specific anyway. Bundling
a font might be nice for consistency (if we can find a good free one), but
not sure how easy it would be to get it into the system font list at install
time.

3.  Do we want the OSD to be a main feature, or something that can be
> optionally compiled in?


I can't think of any reason to make it conditional, so preferably always
compiled in.   I'd also enable it by default, at least for fullscreen mode.

>
>
> 4.  To put a message on the OSD, I currently have it so you use
> display_driver->display_show_osd(...).  This function could also be global
> or a member of something else if this isn't the best location for it.


Yeah this doesn't really belong in the driver code - it's more top-level
stuff.

>
> 5.  Do you think we need to go as far as to have some sort of messaging
> class?  It could push messages to the OSD, status bar, and/or log depending
> on a setting.  This might be a "something else" of #4.


My thinking is that messages generally into one of the following categories:
  * Error - GUI should pop up a message and halt
  * Warn - probably display same as for status (maybe more visible though)
  * Status update (ie info) - GUI should display in the status bar and/or
osd
  * Debug - print to console if enabled, otherwise ignore

So it would make sense to use the INFO() log for status updates. (of course
some of the current INFO messages should really be DEBUG). I don't think
anything more sophisticated is going to be needed at this stage..


> 6.  The saved and loaded OSD messages in there now are more or less
> placeholders until we answer #4 and #5.  I think the final version should
> say which file/slot was saved or loaded, and also have a message when you
> switch quick save slots.


Agreed.


> 7.  I'm guessing not everyone will want to see on screen messages.  I think
> it would be good to have GUI options to toggle the speed from showing up,
> and maybe options regarding whether the OSD messages show when you are in
> windowed mode, fullscreen, or both (since there is the less obtrusive
> status
> bar when you are in windowed mode.  Perhaps this is a good reason to keep
> the status bar messages around?)  An OSD configuration GUI could be the
> start of the currently grayed out Settings->Video menu item.
>

Ok, so we've got something like
    OSD: < always | fullscreen | never > (default fullscreen)
    OSD speed display: < yes | no >  (default no)
I think that works pretty well.


> 8.  Timers.  The OSD messages, if any exist, get rendered every frame, so I
> update the remaining display time every frame.  This is also used to
> smoothly fade out the OSD when its display time is up.  Is this OK or
> should
> it be a g_timeout?  The status message timer would be best switched to a
> g_timeout, but it will also need a special case to keep the speed update
> from clobbering it while another message is being displayed.
>

It probably needs to key off the GUI timer as well, for the same reason
(consistent message times) rather than keeping it's own count. Handling
fadeout smoothly may be tricky though. Speed update is more of an ongoing
thing, so it can update whenever (assuming it occupies a different spot to
the message).


> 9.  I'm an opengl noob.  Let me know if I did anything stupid in my drawing
> code or hooked up osd_render() to the rest of the code in a horrible way
> :-)  Something's still not perfect, as I get a little flickering in the
> text
> on my mythtv box.
>

I'll go through the code properly after I get it to build, but you're
probably being being caught out by the fact that we currently draw directly
to the front buffer and don't bother double-buffering (ie treating the
render texture as the back buffer). Because we're now compositing on top of
the render texture, will probably need to go back to double-buffering.
Basically, (IIRC) glDrawBuffer( GL_BACK ) before drawing into the window,
then video_glx_swap_buffers() at the end. Might need to reset the draw
buffer back to GL_FRONT afterwards, I'm not sure off the top of my head.

Cheers,
Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lxdream.org/pipermail/lxdream-dev-lxdream.org/attachments/20090712/91a05c11/attachment-0001.htm>