[Lxdream-dev] OSD work in progress
Jon Ring
jonnyring at gmail.com
Tue Jul 28 20:31:45 PDT 2009
Here is a new patch with some changes. This is what's changed (and what
hasn't):
1. Fonts are now rendered with Freetype 2. Hopefully this works out better
as a cross-platform high-quality option. It automatically anti-aliases the
text which makes it look nicer than the X/GLX version. Both ways generate
display lists, so I could use your X code as a fallback if necessary. Even
if we don't do this, I may refactor the freetype-specific code to a separate
file just to make it easier to read.
2. The code still uses fontconfig at the moment, but I plan to bundle a
font so that fontconfig doesn't get a chance to make any weird font choices
for anyone.
3. I added the GTK configuration dialog for video settings (nothing is
hooked up to configuration values yet). I added an option for font size
because on a PC a smaller font would be readable, whereas on a TV you'd want
a bigger font.
4. I didn't realize just how many INFO messages there were until I started
showing them on the OSD! These and probably the warnings as well are going
to need to be cleaned up, many should probably be switched to DEBUG.
5. The OSD functions are now top-level and initialized in main.c, instead
of tied to the driver.
6. I still need to look at the flickering/double buffering. I also need to
make sure my opengl code doesn't cause any bad side-effects in the rest of
the opengl drawing functions.
Just wanted to let you see where things are at currently. Also, if you
could let me know if Freetype will be ok, that would be helpful. Any other
feedback is always welcome, too.
Thanks,
Jon
On Wed, Jul 15, 2009 at 6:04 PM, Jon Ring <jonnyring at gmail.com> wrote:
> 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/20090728/9e3c3589/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lxdream-osd-wip2.patch
Type: application/octet-stream
Size: 22942 bytes
Desc: not available
URL: <http://lists.lxdream.org/pipermail/lxdream-dev-lxdream.org/attachments/20090728/9e3c3589/attachment-0002.obj>
More information about the Lxdream-dev
mailing list