GitLab

1) Keep a rectangle updated per-screen rather than regenerate each time
2) Strip palette info when putting pixels into rectangles rather than
   during scaling
3) Tighten up the screen locks a bit
4) Don't require a full resend of both screens on an update request
5) Only force a redraw for cursor movement when the cursor is visible
   (And force it whenever the cursor changes)
6) Avoid doubles in interpolation
7) Heavily optimize interpolate_height()
   interpolate_width() likely doesn't need it because it's generally not
   used and also it reads from the next pixel in memory making the
   prefetchers job easier.
8) Fix some memory-leak-on-error issues
9) For ARGB8 XImages, manipulate the data directly rather than through
   XPutPixel()

At this point, the scaling and X11 output time is heavily dominated by
cache misses.  The only really effective way to reduce this hit is to
spread the work across all the L3 caches in the system or move it into
the GPU.

With the latest updates, at the SyncTERM menu, over 90% of the time is
spent in the rendering pipeline, and over 90% of that time is spent
thrashing the caches... the only real easy win left is vectorizing, but
that's highly compiler specific.

To that end, I've switched to -O3 for release builds.  There was a comment
that -finline-functions broke Baja "badly", but that's clearly false since
-f-inline-functions has been part of -O2 for quite a while now, and Baja
doesn't seem any more broken that it ever was.

At least the warnings are gone.

warning: always_inline function might not be inlinable [-Wattributes]

If do_scale ever failed, it would result in graphics buffers not
returning to the pool, resulting in them never being reused.

People are used to thinking about the aspect ratio of displays and
used to not thinking at all about that of pixels.  Most of the modes
are simplt 4:3 modes and the text area is the entire window.  The
only oddball here is the Commodore 64 and 128 40-column modes.
Because they have a border around them that's wider on the sides than
the top/bottom, the display aspect ratio is actually narrower than
a normal NTSC screen (6:5).  It seems the PAL version actually has
square pixels, but nobody has asked for a PAL Commodore mode, and I
think that has a different colour palette too so I'm not doing it.

Just to frustrate DigitalMan a bit, the default custom aspect ratio
is now 4:3 (but can be configured).  At present, modifying the custom
mode while *in* the custom modes "works", which no sane person would
want when adjusting the aspect ratio.

#pragma clang causes an error
__attribute__ not supported

This uses the 720x400 with 9x16 character cell that always made
BBSs look so terrible.

Simplest way is to use the alt-left/right snapping.

Which required a new ciolib option of course.
Only usable in X11 mode at present, though it may land for SDL
this weekend.

Also, we don't need to use pointers for the scaling.

Since we have all odd numbers thanks to the pointy scaler, and we
have 2x thanks to xBR, we should now be able to build any integer
scaling from a combination of those two scalers.

This, of course, assumes you have enough CPU and RAM to actually
do the scaling you want... powers of two will likely be the worst
case for scaling.

Also, do pointy scaling before xBR.

SyncTERM doesn't support any "fat-pixel" modes.

1) Initialize the r2y array for xBR so it actually works.
2) Add a vertical (only) interpolation scaler for aspect ratio enforcement
3) Add a simple muliplier scaler, so that can be removed from x_event.c
4) Use a new graphics buffer free list, which allows tracking last
   drawn screen instead of last bitmap rectangle, removing various hacks
5) Share the Y'CbCr <-> R'dG'dB'd tables between xBR and scale.c

Uses "pointyscale" for x3 and x5
Uses xBR from FFmpeg for x2 and x4
HQx is also included, but unused as it's too slow at x4.