Seems like a good idea, should allow WMs to kill hung processes and
stuff like that.

The XSynchronize disablement is the most important here... didn't
realize it defaulted to enabled, which has been slowing down a *lot*
of stuff for a long time... not that there's much left that benefits
from disabling Synchronized XLib except this new terrible icon thing.

This allows X11 stuff to work properly.

Actually install the colormap we create.
Remove the 48x48 icon.

As it happens, ChromeOS completely ignores the X11 icons and instead
does some weird magic to drag the icon .png file out of the VM and
uses that.  Basically, getting the icon to work appears to mean
putting some properly named files into magic directores.

USize was wrong, PSize wasn't set, and PBaseSize was set, but flag wasn't.

Also, set both _NET_WM_ICON and WMHint icon pixmap

It seems whatever WM XWayland uses doesn't actually use _NET_WM_ICON
like pretty much everything else for the last 30 years does, so we
need to go old-school or settle for the default pengion icon, which
offends me personally.

Use the default visual and depth instead of "best"
Use Xrender for sclaing when library is available and server supports it
Set VisualIsRGB8 when possible

- getscaling() incorrectly used an int intermediate variable
  This would force scaling to an integer value when read.
- Only parse ConfigureNotify events describing a change to the SyncTERM window
  It appears that XWayland on ChromeOS was occasionally sending a
  ConfigureNotify event describing some other window to SyncTERM,
  and that window had a 1x1 size, which would cause SyncTERM to
  assert minimum size again (usually 640x480), which would set
  scaling to 1.0.

There's no good argument for this aside from "it feels more right".

This mirrors commit 1dc4c22a about a year ago that optimized window
dragging, and performs basically the same check (removed a week ago
with commit a59aba35)

Now that bitmap_drv_request_some_pixels() just calls
bitmap_drv_request_pixels(), there's no point in calling expose_rect()
when ev->xexpose.count isn't zero.

- Only call cb_flush() if a new rect was queued.
- Ensure bitmap_drv_request_some_pixels() is only called once in
  response to an expose request.

This should fix issue #565.

Also, do not try to display frames where the scaled height or width
is less than the frame bitmap height or width.

All bitmap drivers now support arbitrary scaling, and the scaling
factor is a double, allowing arbitrary window scaling in all bitmap
modes (making nelgin happy).

While we're here, fix bugs in horizontal interpolation and X window
resizeing.

For graphical modes, this requests that ciolib be initialized in
the specified mode.  For text-based modes (ANSI, Curses, Win32 Console),
this is not used and "current" is used instead.

Now that vstat is what was last drawn on the screen we need to
save/restore the width/height around calls to bitmap_drv_init_mode().

This is just to make it less noise to watch vstat.scaling from gdb.

Seriously, that's not possible.

Should fix auto-curses mode crash.

Create initial window at final size to avoid extra resize at start
- Load vmode before initializing the window
Track scaling whenever the X window is adjusted
Replace x11_window_height/x11_window_width with vstat.winwidth/vstat.winheight
Resize zim from init_mode_internal() to ensure it tracks current size on initial expose
Honour ciolib_initial_scaling
Check xim validity in local_draw_rect() in case of race
Add check to prevent divide-by-zero in handle_resize_event()
Use vstat for current on-screen info, and x_cvstat for desired info
- This allows using vstat.scaling in place of old_scaling
Have scaling set use a new mutex-protected variable
Fill in local_draw_rect() so we don't miss expose
Set max window size based on user area (or root window size if not available)
The WM Cyan uses may hate this...

This absolutely *must* fix the issue in SF ticket 103.

Move snap logic into bitmap
Move new mode window size logic into bitmap

This lock has devolved into a wrapper lock for vstatlock.

The previous tests to detect RGB8 appear to have been insufficient.
This may have resulted in various artifacts such as transparency with
some drivers on some hardware in X11 mode.

I was going to start keeping the old rect around again, but that
idea didn't pan out.  This massive memory leak is what I get for
not doing more commits while tuning.

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.

Fixes X11 window dragging blinkiness.

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.

Fixes issue 56