[Lxdream-dev] OSD work in progress

[Jon Ring]

Sorry if this shows up twice... I don't think the first one made it to the
list.


On Wed, Jul 15, 2009 at 6:02 PM, Jon Ring <jonnyring at gmail.com> wrote:

>
>
> On Sat, Jul 11, 2009 at 8:13 PM, Nathan Keynes <nkeynes at lxdream.org>wrote:
>
>>
>> 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.
>>
>
>
> That's pretty weird that GLU won't even install, from what I can tell it's
> used by some pretty big names like glut and SDL.  Even if you did have it
> working, the mac issues are still a negative for FTGL.
>
>
>
>>
>>
>> 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.
>>
>
>
> I mainly went with FTGL because I figured it would be a nice easy way to do
> fonts in a cross-platform manner.  Unfortunately, our real-world experiences
> here have proven otherwise.  Between your GLX font code below and the source
> of FTGL, I've started looking at rendering the font without FTGL.  It
> shouldn't really have an impact on the font quality, since with a monospaced
> font there aren't as many of those little details such as kerning to
> implement.
>
>
>
>>
>>
>> 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.
>>
>
>
> The more I think about it, the more I lean towards just including a font
> and not worrying about trying to find one on the system.  I don't think we
> necessarily need to get it into the system font list.  I should be able to
> load a font by its absolute path, but then again that raises the issue of
> knowing where we install the font to...
>
>
>
>
>>
>>
>> 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.
>>
>
>
> [#3 - #7] Thanks for the input - I'll aim for this behavior.
>
>
>
>>
>>
>>
>>> 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).
>>
>
> The OSD time is keyed to real time using a struct timeval that gets updated
> every frame, so it should have a consistent message time.  In addition to
> the fading code, g_timeout might also get messy when it comes to
> cancelling/changing the timeout if a new message replaces an old one before
> it expires.  If you think the current method is particularly bad, though,
> I'll change it to the GUI timer.
>
>
>
>>
>>
>>
>>> 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.
>
>
> Now that you say it, that sounds like it has to be right.  I never saw it
> on my desktop because I have sync to vblank enabled by default.
>
>
> Thanks again for your detailed response.
>
> Jon
>
>
>
>
>>
>>
>> Cheers,
>> Nathan
>>
>> _______________________________________________
>> Lxdream-dev mailing list
>> Lxdream-dev at lists.lxdream.org
>> http://lists.lxdream.org/listinfo.cgi/lxdream-dev-lxdream.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lxdream.org/pipermail/lxdream-dev-lxdream.org/attachments/20090715/fcefc44e/attachment-0002.htm>