How do I render text quickly when each character needs separate placement and formatting?

Question

I try to display formatted text on the screen. At first the very simple HTML text is parsed (there are tags like b,u,i) and then each character is rendered using Canvas.TextOut function in appropriate position and font.

The first thing I noticed is, that rendering of every separate character on the canvas is rather slow. The rendering of whole sentence is much faster. It is obvious, when the canvas is forced to repaint, when form is moved around the screen.

One solution would be to cluster the characters with even fonts and render them at once. But it won't help too much, when the formatting is rich. In addition I need the characters to be the discrete entities, which could be rendered in any way. For example, there is no WinAPI to support text alignment taJustify or in block writing...

Another approach is to render on bitmap, or to use wisely ClipRect property of TCanvas (I haven't tried yet).

Anyway, when the same formatted text is displayed in TRichEdit, there is no time penalty by repaint operation. Another quick example are all major browsers, which has no problem to display tons of formated text... do they render each character like I do, but they do it more efficiently ??? I do not know.

So do you know some recipe to speeding up the application (formatted text rendering?).

Thanx for your ideas...

Sample code: (make TForm as big as possible, grab it with mouse and drag it down under screen. When you move it up, you will see "jumpy" movement)

procedure TForm1.FormPaint(Sender: TObject);
var i, w, h, j:integer;
    s:string;
    switch:Boolean;
begin
   w:=0;
   h:=0;
   s:='';
   for j:=0 to 5 do
       for i:=65 to 90 do s:=s + Char(i);

   switch:=False; // set true to see the difference

   if switch then
     begin
     for j:=0 to 70 do begin
         for i := 1 to Length(s) do
         begin
         Form1.Canvas.TextOut(50+ w,h +70 , s[i]);
         w:=w +  Form1.Canvas.TextWidth(s[i]);
         end;
         w:=0;
         h:=h+15;
         end;
     end
    else
      begin
      for j:=0 to 70 do begin
       Form1.Canvas.TextOut(50+ w,h +70 , s);
       w:=w +  Form1.Canvas.TextWidth(s);  // not optimalized just for comparison
       w:=0;                               // not optimalized just for comparison
       h:=h+15;
       end;
      end;
end;

Answer 1

On my pc, it's about twice as fast when you render to a bitmap, and then draw that to the canvas. Well, the slow version becomes twice as fast. The fast version stays the same.

Another optimization that might work. You can also pre-calculate character widths into an array, so you don't have to call canvas.TextWidth() often.

Keep a variable like this

widths:array[char] of byte;

Fill it like this:

for c := low(widths) to high(widths) do
  widths[c] := Canvas.TextWidth(char(c));

Filling this 65536 element array is slow, so perhaps it's better to just create a 65..90 element-array, and drop unicode-support.

Another thing.. Calling Winapi.Windows.TextOut() is faster than canvas.TextOut().

You can actually win a lot with that.

    Winapi.Windows.TextOut(bmp.Canvas.Handle, w, h, @s[i], 1);

Modified version of your code:

// set up of off-screen bitmap.. needs to be resized when the form resizes. 
procedure TForm1.FormCreate(Sender: TObject);
begin
  bmp := TBitmap.Create;
  bmp.SetSize(width,height);
end;

This is

procedure TForm36.PaintIt2;
var h,i,j,w: Integer; s: string;
begin
  w := 0;  h := 0;  s := '';

  for j := 0 to 5 do
    for i := 65 to 90 do
      s := s + Char(i);

  bmp.Canvas.Brush.Color := Color;
  bmp.Canvas.FillRect(bmp.Canvas.ClipRect);
  if Checkbox1.Checked then
  begin
    for j := 0 to 70 do
    begin
      for i := 1 to Length(s) do
      begin
        Winapi.Windows.TextOut(bmp.Canvas.Handle, w, h, @s[i], 1);
        w := w + widths[s[i]];
      end;
      w := 0; h := h + 15;
    end;
  end
  else
    for j := 0 to 70 do
    begin
      bmp.Canvas.TextOut(w, h, s);
      w := 0; h := h + 15;
    end;
  canvas.Draw(0,0,bmp);
end;

I timed the performance with this procedure:

procedure TForm1.Button2Click(Sender: TObject);
var i : Integer; const iterations=300;
begin
  with TStopwatch.StartNew do
  begin
    for I := 1 to iterations do
      PaintIt2;
    Caption := IntToStr(Elapsed.Ticks div iterations);
  end;
end;

Last note:

I've tried disabling cleartype/anti-aliasing, but strangely enough that makes rendering twice as slow! This is how I turned anti-aliasing off:

  tagLOGFONT: TLogFont;

  GetObject(
    bmp.Canvas.Font.Handle,
    SizeOf(TLogFont),
    @tagLOGFONT);
  tagLOGFONT.lfQuality  := NONANTIALIASED_QUALITY;
  bmp.Canvas.Font.Handle := CreateFontIndirect(tagLOGFONT);

Answer 2

Use a profiler, such as AQTime, to find where your code is actually spending its time. Chances are that it will not be TextOut() itself that is taking the most time. You are indexing through a String one character at a time, passing each character to TextOut() and TextWidth(). Neither of those methods accept Char parameters as input, they only take String input instead, so the RTL is spending effort allocating and freeing a lot of temporary Strings in memory, depending on how long your source String is. I've seen things like that kill loop performance.

Answer 3

To avoid flicker, have best performance and still have all advanced text rendering features (like kerning), the answer is using a temporary bitmap.

Drawing text is very fast in Windows, but displaying a pre-computed bitmap will be much faster.

You can divide your layout to render only the shown part of the text. Or try to split your text into "boxes" of text (just like the great TeX engine does), using a cache for the width of each box. But Windows itself does such caching, so only use such technique if you find a real bottleneck, via proper profiling of the whole code.

Do not reinvent the wheel. On real content, you will find out that text rendering is much more complex than imagined, e.g. if you mix languages and layouts (Arabic and English for instance). You should better rely on Windows, e.g. its UniScribe API, for such complex work. When we made our open source pdf engine, we re-used it as much as possible.

For instance, FireMonkey suffers from reinventing the wheel, and fails when rendering complex text content. So using existing APIs is IMHO the best path...