Slow performance on 2D drawing and font rendering

[arcfide]

I'm doing some basic 2d drawing of rectangles, clipping, and font rendering, and the results I'm getting are less than responsive. There is significant lag in the overall frame rate, and profiling data shows that most of the time is spent in R and Each functions. I suspect that input validation and array construction are costing a lot of time and energy. Is there any way to reduce this overhead and make things faster?

[Brian-ED]

There's no exposed way to make it faster.

Here is a snippet to solve your problem quickly:

_←⎕NA rl.pathToBinary,'|DrawRectangle',⊃,/' ',¨rl.(i i i i ('{','}',⍨1↓⊃,/' ',¨1↓Color))

It defines in your scope DrawRectangle with no handling, which shouldn't have issues since it's so simple. (You'd use DrawRectangle instead of rl.DrawRectangle).

However! I've done some benchmarks, and it seems this simple call is also costing a ton of performance. I've found that after calling DrawRectangle exactly 25000 times, the framerate drops dramatically for the test below. It's weird, 60fps no problems at all, then 5fps. The 25000 times is even across frames. I believe now that this framerate drop you're experiencing is an issue with ⎕NA itself or raylib itself, though I will keep debugging and keep you posted.

[Brian-ED]

"test below":

#!/usr/local/bin/dyalogscript
rlDir ← '../link/',⍨⊃1⎕NPARTS''
rl ← 0⎕Fix rlDir,'raylib.apln'
rl.Init rlDir

rec←60 ⋄ cir←400

distFromMiddle ← 170
outerRecs ← distFromMiddleׯ1+2ׯ1+⍳2 2

_←⎕NA rl.pathToBinary,'|DrawRectangle',⊃,/' ',¨rl.(i i i i ('{','}',⍨1↓⊃,/' ',¨1↓Color))

rl.InitWindow 800 800 'Hello!!!'
b←0
:While ~rl.WindowShouldClose⍬
    pos ← rl.GetMousePosition⍬
    rl.BeginDrawing⍬
        rl.ClearBackground rl.color.black
        rl.DrawFPS 40 40
        a←0
        :While a<300
        a+←1
        b+←1
        ⎕←b
        DrawRectangle¨ ⌊,∘rec rec rl.color.white¨ +∘pos¨outerRecs-rec÷2
        :EndWhile
    rl.EndDrawing⍬
:EndWhile
rl.CloseWindow⍬

[Brian-ED]

And btw, if it is true for your case that the pointer handling that raylibAPL's wrapper is the cause of your performance, then I will see to it that it is optimized.
I was actually going to implement some short-cutting in the code for the simple cases, or even just not wrap the simple functions at all, but this performance issue that the test above showed is the priority for now. Do tell if it's the above that's causing issues (so, calling over 25000 times) or if it's actually the raylibAPL handling. You can test that by checking if the non-wrapped bare ⎕NA above fixes your performance issues.

[arcfide]

So, I've tried the above version out, and besides an issue where the rectangles are not rendering in my application, I'm getting slow FPS regardless, in both the test script and my own application (they are similar), somewhere in the space of 10 - 24FPS, though occasionally I can get above 30.

Here's the application with a demo that you can use to see what's happening:

https://github.com/Co-dfns/MicroUI-APL

You need to make sure that raylib is installed into the same directory as the root (see demo code) in order to run the demo. Based on the tests I'm running, at least part of the problem is that text rendering takes a long time (it's faster when I use the default font).

After Raylib is installed, you can test the above with ⎕FIX'mu.apln' ⋄ mu.demo.

[arcfide]

Actually, quick update, looks like I'm able to get 60FPS from your demo, and it goes down to the 12 FPS that I expected when I use the rl.DrawRectangle. However, should the squares that are rendered be so offset from the mouse pointer?

[arcfide]

Update, figured out the color issues with rendering, and now I can use the direct functions and get a higher framerate, though it's still not consistently above 60FPS (40 - 70). I think I need to get a version for DrawTextEx and DrawText now. I was able to figure out the DrawText one, and I'm working on DrawTextEx now.

[arcfide]

Okay, I am close to having DrawTextEx working, but I can't seem to pass the position Vector2 properly. What is the appropriate way to get that working? I am trying to use {F4 F4} but that isn't getting the right data sent to the function.

[Brian-ED]

Few things I've realized. I understand now that string passing to raylibAPL is allocating and de-alocating every call, which isn't ideal. I can avoid and optimize this pretty easily I believe, so I'll work on that.

The behavior of ⎕NA for structs is not reliable and so you may or may not need 0s for padding in some places. I see that it accepts the rl.font type as the first argument, and I was never able to figure out a general rule of thumb for font structs, so I do not know how to figure out a proper signature for DrawTextEx that is platform agnostic.

To educate, here's the relevant information:

Texture ← ⊂'⋄Texture' ⍝ Texture, tex data stored in GPU memory (VRAM)
  Texture,←⊂ u ⍝ id       ⍝ OpenGL texture id
  Texture,←⊂ i ⍝ width    ⍝ Texture base width
  Texture,←⊂ i ⍝ height   ⍝ Texture base height
  Texture,←⊂ i ⍝ mipmaps  ⍝ Mipmap levels, 1 by default
  Texture,←⊂ i ⍝ format   ⍝ Data format (PixelFormat type)
Texture2D ← Texture ⍝ Texture2D, same as Texture

Font ← ⊂'⋄Font' ⍝ Font, font texture and GlyphInfo array data
  Font,←⊂ i             ⍝ baseSize      ⍝ Base size (default chars height)
  Font,←⊂ i             ⍝ glyphCount    ⍝ Number of glyph characters
  Font,←⊂ i             ⍝ glyphPadding  ⍝ Padding around the glyph characters
  Font,←⊂ Texture2D     ⍝ texture       ⍝ Texture atlas containing the glyphs
  Font,←⊂ '=',Rectangle ⍝ recs          ⍝ Rectangles in texture for the glyphs
  Font,←⊂ '=',GlyphInfo ⍝ glyphs        ⍝ Glyphs info data

If you're on linux x86-64, you may need to pad some integers and unsigned integers here with a corresponding fill, though I do not know which.

I will optimize the allocation and free-ing in the drawing function.

[Brian-ED]

And by "padding", i mean adding new integers into places above, and passing 0s in those spots (or anything actually).
So maybe

Font ← ⊂'⋄Font' ⍝ Font, font texture and GlyphInfo array data
  Font,←⊂ i             ⍝ baseSize      ⍝ Base size (default chars height)
  Font,←⊂ i             ⍝ glyphCount    ⍝ Number of glyph characters
  Font,←⊂ i             ⍝ glyphPadding  ⍝ Padding around the glyph characters
  Font,←⊂ Texture2D     ⍝ texture       ⍝ Texture atlas containing the glyphs
  Font,←⊂ i             ⍝ PADDING HERE
  Font,←⊂ '=',Rectangle ⍝ recs          ⍝ Rectangles in texture for the glyphs
  Font,←⊂ '=',GlyphInfo ⍝ glyphs        ⍝ Glyphs info data

(This is an example and is not intended to work)

[Brian-ED]

The performance issue with translation of a apl-object in general can be fixed by splitting the "ToPointers" conversion from the APL objects out of the actual call itself. This can be done only when you know what arguments you're passing.
This means all translation overhead becomes 0, ignoring the initial translation. Literally only one float per argument gets translated by ⎕NA. I've implemented this and tested a bit and it fixes the performance issues very well.

[Brian-ED]

I'm working on an interface to make this nice to use. Currently it's something like cPtrs←'DrawTextEx' rl.PreHandleArgs font ... (where font ... represents the arguments), then pass cPtrs like DrawTextEx←GetOrig 'DrawTextEx' ⋄ DrawTextEx cArgs, then PostHandleArgs cPtrs to de-allocate.

[Brian-ED]

And to clarify, the above is not a universal solution to translation overhead ofcourse, it only works with repeated calls. It is very helpful in determining translation overhead too.
After this I'll work on actually optimizing R, it shouldn't be that slow and I have a few ideas on optimizations.

[arcfide]

The main thing that would help right now is if I had low overhead versions of DrawTextEx and DrawTextCodepoint. I am able to use the other calls directly from their ⎕NA version, but any call with font and Vector2 positions seems to not be working right now. Ironically, the text shows up, but in the wrong position (All shoved in the upper left hand corner).

For my case, while some arguments will be the same, for many of the arguments, they will not be the same, such as positions and the text that is rendered, so I need those to be low overhead in the presence of change.