Opacity in s/w RenderShaded

SDL Development
1

Hi, I’m using RenderShaded with red foreground and white background,
and I get pale pink. I’ve tried with red opacity set to both 0 and 255,
it makes no difference. (I actually want to render a solid red on a white
background). This is using TTF.

[TTF is very annoying because Render Solid includes negative left offsets in
the surface … but Render Shaded does not which makes rendering a line
where both are required tricky. I think the API is not so good, it would be better
for the client to supply the surface on which to render than have the rendering
functions return a surface]–
john skaller
@john_skaller
http://felix-lang.org

2

Hi, I’m using RenderShaded with red foreground and white background,
and I get pale pink. I’ve tried with red opacity set to both 0 and 255,
it makes no difference. (I actually want to render a solid red on a white
background). This is using TTF.

Ooops. My bad. Wrong numbers for red lol!

However this is a bug I think:

When I render Courier New at 12 point with RenderSolid, the “e” is one
pixel too high. I thought this might be a bug in the font, but it isn’t:
the “e” is in the correct place when I use RenderShaded.

Yep, it’s only lowercase “e”. I can get really accurate picture on the
Macbook Pro because there’s a way to magnify the screen.On 13/07/2013, at 6:15 AM, john skaller wrote:

–
john skaller
@john_skaller
http://felix-lang.org

3

This is probably an artifact of the way FreeType does it’s rasterization.
In the solid case it has to make decisions about where to place the glyphs
on pixel boundaries, where the shaded and blended case it can simulate
subpixel precision.

I would recommend always using the shaded version for the most readable
text. You may want to set TTF_HINTING_LIGHT to more accurately match
Windows and Mac OS X font weights.On Fri, Jul 12, 2013 at 3:48 PM, john skaller <skaller at users.sourceforge.net wrote:

On 13/07/2013, at 6:15 AM, john skaller wrote:

Hi, I’m using RenderShaded with red foreground and white background,
and I get pale pink. I’ve tried with red opacity set to both 0 and 255,
it makes no difference. (I actually want to render a solid red on a white
background). This is using TTF.

Ooops. My bad. Wrong numbers for red lol!

However this is a bug I think:

When I render Courier New at 12 point with RenderSolid, the “e” is one
pixel too high. I thought this might be a bug in the font, but it isn’t:
the “e” is in the correct place when I use RenderShaded.

Yep, it’s only lowercase “e”. I can get really accurate picture on the
Macbook Pro because there’s a way to magnify the screen.

–
john skaller
skaller at users.sourceforge.net
http://felix-lang.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

This is probably an artifact of the way FreeType does it’s rasterization. In the solid case it has to make decisions about where to place the glyphs on pixel boundaries, where the shaded and blended case it can simulate subpixel precision.

That makes sense. The middle horizontal line of the “e” lines up with
that in “F” and “E” etc so that is quite a reasonable guess.

I would recommend always using the shaded version for the most readable text.

Ok, I will try that, but I have a performance issue here: my editor technology redraws
the whole screen every modification, in principle the decoupling between the
display and editing functions make the thing simple. I recently switched from
displaying text lines to characters (to support syntax highlighting) and the speed
difference is perceptible. [by which I mean, unacceptable] Guess I’ll need to do some caching.

I’m stiil using a software renderer then blitting to the window surface,
probably I should move to HW rendering.

You may want to set TTF_HINTING_LIGHT to more accurately match Windows and Mac OS X font weights

Ok, I’ll try that too. On OSX fonts are a bit confusing, because there are system fonts
and then each application can also have its own. My iTerm for example has fonts
I can’t find anywhere :-)On 13/07/2013, at 3:24 PM, Sam Lantinga wrote:

–
john skaller
@john_skaller
http://felix-lang.org

5

Message-ID:
<3D292734-D1AD-42D9-838F-70741E82F097 at users.sourceforge.net>
Content-Type: text/plain; charset=us-ascii

I would recommend always using the shaded version for the most readable
text.

Ok, I will try that, but I have a performance issue here: my editor
technology redraws
the whole screen every modification, in principle the decoupling between
the
display and editing functions make the thing simple. I recently switched
from
displaying text lines to characters (to support syntax highlighting) and the
speed
difference is perceptible. [by which I mean, unacceptable] Guess I’ll need
to do some caching.

I’m stiil using a software renderer then blitting to the window surface,
probably I should move to HW rendering.

I assume that you’re using a SW render-target instead of digging into
the guts of the renderer. Have you tried using a HW render target in
your current configuration? People like me don’t have the hardware to
support it, but I actually said that I was an example of what should
be disregarded when render targets were being pushed in. Give HW
render targets a try, and see if that speeds things up enough.> Date: Sun, 14 Jul 2013 00:18:55 +1000

From: john skaller
To: SDL Development List
Subject: Re: [SDL] opacity in s/w RenderShaded
On 13/07/2013, at 3:24 PM, Sam Lantinga wrote:

6

I assume that you’re using a SW render-target instead of digging into
the guts of the renderer.

Yes, that’s right.

Have you tried using a HW render target in
your current configuration?

Not yet. In principle I don’t have any “current configuration”,
like many SDL based products the intent is to make stuff run
"anywhere" ***. I started out with SW rendering simply because
it was easier to render onto a surface and use blits. Get used to SDL
again before delving into nasty graphics stuff :slight_smile:

People like me don’t have the hardware to
support it, but I actually said that I was an example of what should
be disregarded when render targets were being pushed in. Give HW
render targets a try, and see if that speeds things up enough.

However I expect the problem is the overhead calling SDL_ttf
every char, which means allocating a surface every char, only to
"blit" it onto the window surface.

I guess its a limitation of freetype that it renders fonts as pixels
instead of using pens and brushes directly in an GPU context.On 14/07/2013, at 12:26 PM, Jared Maddox wrote:

–
john skaller
@john_skaller
http://felix-lang.org

7

This is probably an artifact of the way FreeType does it’s rasterization.
In the solid case it has to make decisions about where to place the glyphs on pixel boundaries,
where the shaded and blended case it can simulate subpixel precision.

That makes sense. The middle horizontal line of the “e” lines up with
that in “F” and “E” etc so that is quite a reasonable guess.

Sam’s correct in that it’s an artifact of FreeType operating in all of
1/65536ths, 1/64ths and 1/1ths of a pixel at once.

However, perceived difference between solid and shaded is an artifact
of chosen font and line height - it may as well
manifest differently for some other combination.

Ok, I will try that, but I have a performance issue here: my editor technology redraws
the whole screen every modification, in principle the decoupling between the
display and editing functions make the thing simple. I recently switched from
displaying text lines to characters (to support syntax highlighting) and the speed
difference is perceptible. [by which I mean, unacceptable] Guess I’ll need to do some caching.

I’m stiil using a software renderer then blitting to the window surface,
probably I should move to HW rendering.

You will have to aggressively cache whatever SDL_ttf (and, ultimately,
FreeType + any shaping) returns to you.
That would be per horizontal line of text at the coarsest level, might
need to be even finer-grained than that.

There is literally no other way.

If you want it stay closer to hardware, you could try to fiddle with
pixel formats (GL buffers and attempt putting all your cache backing
store into GPU memory, dropping SDL rendering entirely).

I stopped at caching intensity+glyph attribution (for highlights and
such) per unicode character in main memory.

Here’s a bug-ridden example: https://github.com/lxnt/zhban

Note the difference between unicode code point (character for
simplicity) and the font glyph. It’s an one-way N:M map without any
generic way to determine it - and that’s if only ligatures are used.
You don’t really want to learn this all unless you absolutely can not
either drop all the fancy stuff like ligatures or use Pango for your
text-editor-rendering needs.

Ah, and yes, forgot to mention - it is not possible to determine a
pixel size of a string rendered via FreeType without a dry-run
rendering. This applies to everything (and any other font renderer)
except for bitmap fonts.On Sat, Jul 13, 2013 at 6:18 PM, john skaller wrote:

On 13/07/2013, at 3:24 PM, Sam Lantinga wrote:

–

./lxnt