Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matt]

I'm in the process of updating the text drawing in Media Center.

It gets a little technical to talk about how it works now, but basically the drawing always funnels through the Windows SDK.  And the regular Windows API doesn't support the alpha channel when drawing text, so we jump through hoops to support alpha (a second render, conversion of that render, then a final render).  More and more places in the program require alpha support, so this has become an increasing problem.

The new system will use the Windows API one time, and then use internal functions.

This will bring several advantages:
1) Text drawing will be faster (maybe lots faster, but I'm not sure yet)
2) Text that draws with alpha (Theater View, etc.) will support ClearType (color shifting to improve apparent smoothness)
3) All text drawing will support alpha, so drawing with alpha support will be just as fast as no-alpha drawing

This isn't exactly a killer feature, but it's a small touch that will make the program look a little better and work a little faster.

[raym]

Sounds great Matt. Thanks for sharing.

[MrHaugen]

It amazes me what things you tune in this application to make it better. Sure, such things might sound dull. But as you bring builds after builds with features, improvements and tuning, the application is actually more and more responsive, and a tad faster now and then. Not bloated and slower for each new major version as the standard of software development normally is.

Kudos!

[jgreen]

Matt, it is a priviledge to watch you guys go at it.  Not just the JRiver propellerheads, but many of the contributors on this beta board make meaningful contributions to the end product (er, I'm not one of those guys).  Onward!!

[Matt]

The updated text drawing system will be in tonight's build.

The performance looks like:
4.4x faster drawing of text with alpha (most parts of the program)
2.8x faster drawing of simple text without alpha (a few parts of the program)
3.9x faster drawing of text with drop shadow (Theater View, etc.)
3.8x faster measuring text sizes (used everywhere)
76.9x faster drawing one character at a time (edit control, etc.)

The ClearType support in Theater View creates better looking text there.

SSE4.1 is required for drop shadow and outline effects.  I'm not sure if we'll write a slow fallback for these or not.

This change removes our limited support for right-to-left text.  We will revisit this issue once the rest of the text engine changes are settled.

As always, testing and feedback appreciated.

[mojave]

As always, testing and feedback appreciated.

Can I get my screen name title changed to MC Alpha Team? 

[JimH]

Can I get my screen name title changed to MC Alpha Team?  

Done.  We'll change it back when you report a few bugs. 

[jmone]

Not bloated and slower.... for each new major version as the standard of software development normally is.

What!  The installer is now over 20MB + other downloads (like the Direct Show filter) - sloppy coding I say as it has almost doubled since MC12 (when I started).  Oh hold on.....  by comparison, the Amazon Kindle app on my android is 14mb....and it only displays books (+ siphons $ from your credit card)....    Great work!

[mojave]

Done.  We'll change it back when you report a few bugs.

Ha, Ha, Ha! I meant the "title," not the user name, but I think you know that.   Now when I help someone they will wonder who this MC Alpha Male is that is posting in their thread.  

I did find a nice avatar to go with my new user name.  

Edit:  The use of Glynor's picture is meant as a compliment. The beard, the "motion" with the hair blown back, and the clouds make it look like a leader with superior prowess.

[JimH]

Zeus

[MrC]

Now when I help someone they will wonder who this MC Alpha Male is that is posting in their thread.

I'll quickly retreat from the thread, cowering, and wetting myself along the way.

[laerm]

I'm in the process of updating the text drawing in Media Center.

It gets a little technical to talk about how it works now, but basically the drawing always funnels through the Windows SDK.  And the regular Windows API doesn't support the alpha channel when drawing text, so we jump through hoops to support alpha (a second render, conversion of that render, then a final render).  More and more places in the program require alpha support, so this has become an increasing problem.

The new system will use the Windows API one time, and then use internal functions.

This will bring several advantages:
1) Text drawing will be faster (maybe lots faster, but I'm not sure yet)
2) Text that draws with alpha (Theater View, etc.) will support ClearType (color shifting to improve apparent smoothness)
3) All text drawing will support alpha, so drawing with alpha support will be just as fast as no-alpha drawing

This isn't exactly a killer feature, but it's a small touch that will make the program look a little better and work a little faster.

Hey Matt, I just came over to this thread from the MC18 dev history thread (thanks to the email upgrade pricing, I now know MC18 is ready to roll so I thought I'd check it out).

I am 99.99% certain that nobody will have greater interest in how the new font rendering works than myself. You see, I hint fonts for a living (in addition to some other font production work). That being said, having ClearType in Theatre View is great, but CT behaves strangely when it's used on knockout text. At the resolutions and ppem sizes that are appropriate for CT, this probably will have little effect, but I don't doubt that it will be create issues on smaller sized text (16ppem and smaller, perhaps). I...dunno if that matters too much, but typographers are paid to be pedantic, so here I am.

Second, is it "just" CT or is it CT with y anti-aliasing, a/k/a DirectWrite? Last time I checked, MC was still using Chromium, and CTwYAA is only available in IE (or Win . What are you thinking about this? CTwYAA would help much more with the knockout text problem I mentioned above.

Really, the main reason I'm posting about this? I'm geeked to talk font rendering with a guy who works on my favorite piece of non-work software. 

Thanks!
Micah

[Matt]

Hi laerm,

It sounds like you know (a lot) more about fonts than I do.  So I'm not sure how smart of answers I can give.

We let Windows draw each glyph one time.  So the quality of the render is still dependent on Windows and the font.

After that, all rendering is done by us.  This is where the huge speed-ups came from, because we can talk directly to an image buffer much faster than GDI is able to.  It also allows much cleaner alpha-channel support (since GDI is bad at this).

When Media Center shows a webpage view, we use an external engine (IE or Chromium) so text rendering is out of our control.  These are the only areas of the program that I can think of where this is the case.

We never let the GPU render the text, at least not directly.  Theater View text is rendered by our regular text engine, then placed on a hardware buffer.  This means we're controlling the output per-pixel, just like drawing a thumbnail or any other hardware buffer.

[lowjoel]

Might be a little too late, and perhaps too much of an engineering effort; but DirectWrite does produce visibly (to me anyway) cleaner output especially with ClearType on, as laerm pointed out. So maybe in a future version? Though I do admit that it's only going to make sense for the Windows port.

Any speed up now will be nice though Though being SSE4.1 all except the newest computers would support it.

[laerm]

Hi laerm,

It sounds like you know (a lot) more about fonts than I do.  So I'm not sure how smart of answers I can give.

We let Windows draw each glyph one time.  So the quality of the render is still dependent on Windows and the font.

After that, all rendering is done by us.  This is where the huge speed-ups came from, because we can talk directly to an image buffer much faster than GDI is able to.  It also allows much cleaner alpha-channel support (since GDI is bad at this).

Haha, it's OK, I'm used to everyone leaving the room when I get going. At any rate, thanks for the info. That was sorta what I expected would be the case, that Windows would do the render, but I didn't know how much access to the process you guys had. As where I was leading...

Might be a little too late, and perhaps too much of an engineering effort; but DirectWrite does produce visibly (to me anyway) cleaner output especially with ClearType on, as laerm pointed out. So maybe in a future version? Though I do admit that it's only going to make sense for the Windows port.

...DWrite will be MUCHO helpful with Theatre View (thanks lowjoel, you're dead-on!). Everyone will just have to wait for Win8 to see it, I guess. Have you done tests on your end, Matt, as to how Win8 looks in comparison? It should look like night and day.

In other news, perhaps the wrong place for this, but it seems MC18 isn't letting me choose OTF fonts for font in Theatre View. I can pick it, but it doesn't go in Theatre View and when I go back to the options panel it's reverted to Segoe UI.

Thanks!
Micah

[lowjoel]

IIRC DWrite was supposed since Vista (otherwise it's Windows 7), so why is there a need for Windows 8?

[laerm]

IIRC DWrite was supposed since Vista (otherwise it's Windows 7), so why is there a need for Windows 8?

IIRC (two in a row!), DWrite as released in Win7 only included the aspects for multilingual text entry, layout, and rendering (replacing Uniscribe), as well as the enhanced OpenType capabilities. A non-mandatory update pushed out the y anti-aliasing. It's otherwise available in Win7 in IE9. I believe Win8 supports every aspect of DWrite OS-wide. (I could be wrong; I can't remember when this was first a big deal for us at work.)

Micah

[lowjoel]

Possibly. But I think that the DWrite APIs are very different from the GDI ones, so they should be substantially different and probably difficult to replace OS-wide.

But hey, I'm not Microsoft

[laerm]

Possibly. But I think that the DWrite APIs are very different from the GDI ones, so they should be substantially different and probably difficult to replace OS-wide.

But hey, I'm not Microsoft

Hm, and I know next to nothing about APIs, so you could very well be right. Well, if this isn't one of the internet's most gentlemanly discussions ever.

Micah

[6233638]

Are there any plans to further improve the font rendering?

Text is being rendered with full saturation on the subpixel rendering, which looks awful on my display.

1. MC18
2. Firefox, which allows you to set font rendering to "natural symmetric", and reduce saturation via "gfx.font_rendering.cleartype_params.cleartype_level", along with a number of other controls.
3. Notepad, using the system ClearType settings. (I just ran the ClearType tuner)

[kurushi]

I was ok with fonts in MC but when i have tried the new mediaportal i was surprised with the font rendering and think about inMC now it's possible thx matt because font are the most predominant visual in mc (there's hundred stuff to read in MC).
When do u think the release will be available?

[Matt]

3. Notepad, using the system ClearType settings. (I just ran the ClearType tuner)

Notepad uses Segoe UI / Light / 10.

MC uses the default UI font Segoe UI / Normal / 9.

So they won't match exactly.  We use the lfMessageFont returned by SystemParametersInfo(SPI_GETNONCLIENTMETRICS), which I think is the default UI font (unless there's some other way to load the default font).

[6233638]

I changed the font to Arial (I think?) at the same size for the comparison so that they would be the same. Firefox looks different due to it using natural symmetric.
Natural changes the kerning (spacing between letters) and symmetric means it has both horizontal and vertical antialiasing rather than just horizontal, which makes it softer (particularly smaller fonts) but more accurate - it's definitely not for everyone.
Most applications render text as notepad does in that example, but Firefox is the ideal in my opinion - very little color fringing and a nice smooth appearance.

I don't really know much about the technical side of implementing the font rendering though - I just know that the way text is rendered inside MC18 looks like the ClearType Tuner does before you change the saturation level - at one stage it shows you the full saturation, desaturated, and grayscale font rendering next to each other to pick from.

The reason I used Firefox as an example though, is that you can easily change the parameters with about:config open in one window, and some sample text or a webpage open in another, which changes as you edit the gfx.font_rendering.cleartype settings, and it has a setting that lets you change the saturation from 0-100 easily, so I was hoping that this would be something MC18 could do.

[Matt]

Most applications render text as notepad does in that example, but Firefox is the ideal in my opinion - very little color fringing and a nice smooth appearance.

I compared the address bar in Firefox to an edit control in Media Center.  They match basically to the pixel (although Noire uses slightly softer colors than black on white, so there's a little less contrast).

I'm not sure what might be different on your system.

Since we use the OS to render the glyph the first time, I would expect all the global settings for ClearType to be honored.

[6233638]

Sorry I didn't make that clear, I'm using custom settings in Firefox:

(note: pixel structure should be set to 1 for RGB - my display uses BGR subpixels)

cleartype_level will adjust the saturation, and by default Firefox does not follow the system settings. (in fact, I'm not sure that it can)

Firefox was an example of how I wish the font rendering was, rather than how the OS is set - notepad follows the OS settings, and looks the same as other applications.

Since we use the OS to render the glyph the first time, I would expect all the global settings for ClearType to be honored.

I wish I could be more help with this, but I don't know why it's rendering at full saturation even if the system is not set that way via the ClearType Tuner.

[6233638]

Well I still think text rendering could be improved, but I'm just posting here because I noticed that text rendered in Theater Mode is being rendered as RGB rather than BGR. (I don't normally use it, as I don't have a good way to control it)
Text in other views is correctly rendered as BGR.

[Matt]

Well I still think text rendering could be improved, but I'm just posting here because I noticed that text rendered in Theater Mode is being rendered as RGB rather than BGR. (I don't normally use it, as I don't have a good way to control it)
Text in other views is correctly rendered as BGR.

Could you expand on what you mean, or post a screenshot?

I tested this expression in Standard View and Theater View:
<font color="ff0000">Color!<//font>

It's red in both.

You'll need the updated build to test that expression yourself, because it includes:
Changed: Basic HTML text formatting tokens like < b >, < font >, < u >, etc. will be supported in almost all text drawing (previously they only worked in some areas of the program).

[6233638]

Sorry that wasn't clear. The subpixel font rendering is RGB in Theater mode, rather than BGR, which my display stupidly uses.



Other views are using BGR correctly.

And actually, it looks like this may be rendering with the correct saturation, unlike the other views - but I would have to do more testing to check that.