BlueMonkMN's picture

TextPrinter Update

I'm in the process of enhancing TextPrinter to support alignment and word wrap etc. (using MeasureCharacterRanges). I noticed the following code in PerformLayout:

            while (8 * charPositions.Length > vertices.Length)
               vertices = new Vector2[vertices.Length << 1];
 
            while (6 * charPositions.Length > indices.Length)
               indices = new ushort[indices.Length << 1];

Wouldn't it be much more efficient to do this?

            int newLength = vertices.Length;
            while (8 * charPositions.Length > newLength)
               newLength = newLength << 1;
            if (newLength > vertices.Length)
               vertices = new Vector2[newLength];
 
            newLength = indices.Length;
            while (6 * charPositions.Length > newLength)
               newLength = newLength << 1;
            if (newLength > indices.Length)
               indices = new ushort[newLength];

(Ignore the fact that I'm using charPositions.Length instead of text.length for the time being.)

Edit: Attached updated source code.

AttachmentSize
Fonts.zip8.54 KB

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture

Probably more like:

"Have you tried OpenTK?"
"Yeah, it's a great OpenGL API for C#. They got some simple built-in font noone uses - I feel bad for the guy who wasted days of his life tweaking that thing - because their Font class allows chosing any .ttf font at any size you want.
There's also this awesome Fluid simulation demo in the projects section. It's quite fun to play around with that, you should take a look."

Seriously, why add a default font, but not a default Texture, default Soundfile, etc.? Those are artist products, they don't even give the slightest hint about the programmer's API.

objarni's picture

Inertia, the fonts of OpenTK right now are not up to par.

It's been a few months in that not-working-state now. Judging from the tons of discussions on the font topic, it is nothing that will be crystal clear anytime soon either. Fix them, and I'll stop whining.

Until the general font rendering are working, a small USABLE font would be a great tension reliever.

And, such a font could have positive effects on the OpenTK brand, instead of negative as is the case for the artefacts.

Artefacts just don't look good, and human beeings have good eyes! For good or worse.

my 2cc

the Fiddler's picture

Objarni, I think you are blowing the issue way out of proportion:

  1. The artifacts only affect specific intel chips/drivers.
  2. The lack of grid-fitting causes glyphs to appear blurred on Windows (not Linux), but this is not world shattering. Besides, a bitmap font such as the one you suggest would suffer from the very same issues.

If you really find these issues disturbing, implementing and debugging a simple bitmap font-renderer won't take more than a day. You can then package it into a dll so that other people can benefit (I'll gladly host the code if you wish).

Also, despite what it looks like, this issue isn't dead and buried - I'm actively testing native solutions like Uniscribe/Pango/Atsui (the ones mozilla/gecko is based on). I'm not saying these are suitable for OpenTK (imagine 2-3 KLOC for each one, not counting the p/invokes), I'm just indicating that fonts are a topic without easy solutions.

BlueMonkMN's picture

Are you still "comparing and contrasting differences between MeasureCharacterRanges and MeasureString, trying to figure out exactly how StringFormat affects each"? Are you waiting for more from me, or are you going to pick it up from here? I've been busy with other things lately, and am not sure I can get back into the swing of text output, but I don't want to hold things up -- I can look into it again if nobody else is getting anywhere with this.

the Fiddler's picture

I think I've found a solution - expect an update soon.

BlueMonkMN's picture

Are we talking days, weeks or months?

the Fiddler's picture

Ahem, this is already implemented. Take a look at this thread.

BlueMonkMN's picture

My understanding after reading the other thread is that this is still a work in progress. I'm not clear on whether the interface is finalized, though. If the interface is pretty much set (for measuring and outputting text) I could at least integrate that and then just wait for the implementation to work itself out. Are you still working on ideas that might change the interface? (Is it committed to source control?)