cursor from 16x16 (with 6 columns unused) to 10x16 and rename it to
the "small" cursor. Add a "large" 19x32 cursor and use it for screen
widths larger than 800 pixels. Use libvgl's too-small indentation for
the large data declarations.
MOUSE_IMG_SIZE = 16 is still part of the API. If an application supplies
invalid bitmaps for the cursor, then the results may be different from
before.
complications in the previous methods.
r346761 broke showing the mouse cursor after changing its state from
off to on (including initially), since showing the cursor uses the
state to decide whether to actually show and the state variable was
not changed until after null showing. Moving the mouse or copying
under the cursor fixed the problem. Fix this and similar problems for
the on to off transition by changing the state variable before drawing
the cursor.
r346641 failed to turn off the mouse cursor on exit from vgl. It hid
the cursor only temporarily for clearing. This doesn't change the state
variable, so unhiding the cursor after clearing restored the cursor if its
state was on. Fix this by changing its state to VGL_MOUSEHIDE using the
application API for changing the state.
Remove the VGLMouseVisible state variable and the extra states given by it.
This was an optimization that was just an obfuscation in at least the
previous version.
Staticize VGLMouseAction(). Remove VGLMousePointerShow/Hide() except as
internals in __VGLMouseMode(). __VGLMouseMouseMode() is the same as the
application API VGLMouseMouseMode() except it returns the previous mode
which callers need to know to restore it after hiding the cursor.
Use the refactoring to make minor improvements in a simpler way than was
possible:
- in VGLMouseAction(), only hide and and unhide the mouse cursor if the
mouse moved
- in VGLClear(), only hide and and unhide the mouse cursor if the clearing
method would otherwise clear the cursor.
cursor must be merged with the shadow buffer on the way to the screen,
and __VGLBitmapCopy() now has an option to do exactly that. This is
insignificantly less efficient.
hiding the mouse cursor. The showing and hiding is often done
asynchronously in a not very safe signal handler, but the state of
these registers and much more is protected from the signal handler
in a better way by deferring mouse signals while the state is in use.
VGLMouseFreeze() now only defers mouse signals and leaves it to higher
levels to hide and unhide the mouse cursor if necessary. (It is never
necessary, but is done to simplify the implementation. It is slow and
flashes the cursor. It is still done for copying bitmaps and clearing.)
VGLMouseUnFreeze() now only undoes 1 level of freezing. Its old
optimization to reduce mouse redrawing is too hard to do with unhiding
in higher levels, and its undoing of multiple levels was a historical
mistake.
VGLMouseOverlap() determines if a region overlaps the (full) mouse region.
VGLMouseFreezeXY() is the freezing and a precise overlap check combined
for the special case of writing a single pixel. This is the single-pixel
case of the old VGLMouseFreeze() with cleanups.
Fixes:
- check in more cases that the application didn't pass an invalid VIDBUF
- check for errors from copying a bitmap to the shadow buffer
- freeze the mouse before writing to the shadow buffer in all cases. This
was not done for the case of writing a single pixel (there was a race)
- don't spell the #defined values for VGLMouseShown as 0, 1 or boolean.
worked right for white interiors and black borders was used). Advertise
this by changing the default colors to a red interior and a white
border (the same as the kernel default). Add undocumented env variables
for changing these colors. Also change to the larger and better-shaped
16x10 cursor sometimes used in the kernel. The kernel choice is
fancier, but libvgl is closer to supporting the larger cursors needed
in newer modes.
The (n)and-or logic for the cursor doesn't work right for more than 2
colors. The (n)and part only masks out all color bits for the pixel
under the cursor when all bits are set in the And mask. With more
complicated logic, the non-masked bits could be used to implement
translucent cursors, but they actually just gave strange colors
(especially in packed and planar modes where the bits are indirect
through 1 or 2 palettes so it is hard to predict the final color).
They also gave a bug for writing pixels under the cursor. The
non-masked bits under the cursor were not combined in this case.
Drop support for combining with bits under the cursor by making any nonzero
value in the And mask mean all bits set.
Convert the Or mask (which is represented as a half-initialized 256-color
bitmap) to a fully initialized bitmap with the correct number of colors.
The 256-color representation must be as in 3:3:2 direct mode iff the final
bitmap has more than 256 colors. The conversion of colors is not very
efficient, so convert at initialization time.
code for reading from the frame buffer.
Reading from the frame buffer is usually much slower than writing to
the frame buffer. Typically 10 to 100 times slower. It old modes,
it takes many more PIOs, and in newer modes with no PIOs writes are
often write-combined while reads remain uncached.
Reading from the frame buffer is not very common, so this change doesn't
give speedups of 10 to 100 times. My main test case is a floodfill()
function that reads about as many pixels as it writes. The speedups
are typically a factor of 2 to 4.
Duplicating writes to the shadow buffer is slower when no reads from the
frame buffer are done, but reads are often done for the pixels under the
mouse cursor, and doing these reads from the shadow buffer more than
compensates for the overhead of writing the shadow buffer in at least the
slower modes. Management of the mouse cursor also becomes simpler.
The shadow buffer doesn't take any extra memory, except twice as much
in old 4-plane modes. A buffer for holding a copy of the frame buffer
was allocated up front for use in the screen switching signal handler.
This wasn't changed when the handler was made async-signal safe. Use
the same buffer the shadow (but make it twice as large in the 4-plane
modes), and remove large special code for writing it as well as large
special code for reading ut. It used to have a rawer format in the
4-plane modes. Now it has a bitmap format which takes twice as much
memory but can be written almost as fast without special code.
VIDBUFs that are not the whole frame buffer were never supported, and the
change depends on this. Check for invalid VIDBUFs in some places and do
nothing. The removed code did something not so good.
not doing any unnecessary PIO instructions or refusing to start when the
i/o privilege needed for these instructions cannot be acquired.
This turns off useless palette management in direct modes. Palette
management had no useful effect since the hardware palette is not used
in these modes.
This transiently acquires i/o privilege if possible as needed to give
VGLSetBorder() and VGLBlankDisplay() a chance of working. Neither has
much chance of working. I was going to drop support for them in direct
modes, but found that VGLBlankDisplay() still works with an old graphics
card on a not so old LCD monitor.
This has some good side effects: reduce glitches for managing the palette
for screen switches, and speed up and reduce async-signal-unsafeness in
mouse cursor drawing.
method as in /bin/sh.
We still do technically undefined things in the signal handler, but it
is safe in practice to access state that is protected by INTOFF/INTON.
In a recent commit, I sprinkled VGLMouseFrozen++/-- operations in
places that need INTOFF/INTON. This prevented clobbering of pixels
under the mouse, but left mouse signals deferred for too long. It is
necessary to call the signal handler when the count goes to 0. Old
versions did this in the unfreeze function, but didn't block actual
signals, so the signal handler raced itself. The sprinkled operations
reduced the races, but when then worked to block a race they left
signals deferred for too long.
Use INTOFF/INTON to fix complete loss of mouse signals while reading
the mouse status. Clobbering of the state was prevented by SIG_IGN'ing
mouse signals, but that has a high overhead and broke more than it
fixed by losing mouse signals completely. sigprocmask() works to block
signals without losing them completely, but its overhead is also too
high.
libvgl's mouse signal handling is often worse than none. Applications
can't block waiting for a mouse or keyboard or other event, but have
to busy-wait. The SIG_IGN's lost about half of all mouse events while
busy-waiting for mouse events.
Reading of single pixels didn't look under the cursor.
Copying of 1x1 bitmaps didn't look under the cursor for either reading
or writing.
Copying of larger bitmaps looked under the cursor for at most the
destination.
Copying of larger bitmaps looked under a garbage cursor (for the Display
bitmap) when the destination is a MEMBUF. The results are not used, so
this only wasted time and flickered the cursor.
Writing of single pixels looked under a garbage cursor for MEMBUF
destinations, as above except this clobbered the current cursor and
didn't update the MEMBUF. Writing of single pixels is not implemented
yet in depths > 8. Otherwise, writing of single pixels worked. It was
the only working case for accessing pixels under the cursor.
Clearing of MEMBUFs wasted time freezing the cursor in the Display bitmap.
The fixes abuse the top bits in the color arg to the cursor freezing
function to control the function. Also clear the top 8 bits so that
applications can't clobber the control bits or create 256 aliases for
every 24-bit pixel value in depth 32.
Races fixed:
Showing and hiding the cursor only tried to avoid races with the mouse
event signal handler for internal operations. There are still many
shorter races from not using volatile or sig_atomic_t for the variable
to control this. This variable also controls freezes, and has more
complicated states than before.
The internal operation of unfreezing the cursor opened a race window
by unsetting the signal/freeze variable before showing the cursor.
depths for the source and target are not supported. The bits for higher
numbered planes (mostly for red) were either not copied or were copied to
lower numbered planes for nearby pixels.
Quick fix for creation of mouse cursor bitmaps in all depths. This fix is
only complete for the default lightwhite cursor with a black frame.
Even the lightwhite and black colors are hard to find. The templates
use 0xff for lightwhite, but that means brightblue in the simplest mode
(Truecolor depth 24). Other modes are even more complicated -- they are
singly or doubly indirect throught palette(s) and changing of the palettes
by applications is supported.
Details:
Replicate the template value for Truecolor modes to fill out the target
depth (and more for depths not a multiple of 8). Do this for every
drawing of the cursor so that it sort of works for mouse cursor bitmaps
set by applications.
Use 0xf for lightwhite in most other modes. Only do this for the
default cursor so that it doesn't affect mouse cursor bitmaps set by
applications. 0xf mostly works because it was originally for CGA
lightwhite and is emulated using 1 or 2 indirections on EGA and VGA.
0x3f (EGA white) and 0xff (VGA black) direct palette indexes mostly
don't work since backwards compatibility inhibits or prevents them
representing lightwhite. But 0x3f (EGA white) must be used for mode
37 (VGA_MODEX) (320x240x8 V) since this mode is closer to EGA than VGA.
VGLBitmapString() and VGLSetBorder() so as to not truncate to 8 bits.
Complete the corresponding fix for VGLGetXY() and VGLPutXY() (parts
of the man page were out of date).
Support for 16-bit and 32-bit Truecolor modes was supposed to be
complete in r70991 of main.c and in nearby revisions for other files, but
it was broken by the overruns in most cases (all cases were the mouse
is enabled, and most cases where bitmaps are used). r70991 also
uninintentionally added support for depths 9-15, 17-23 and 25-31.
Depth 24 was more obviously broken and its support is ifdefed out. In
the other ranges, only depth 15 is common. It was broken by buffer
overruns in all cases.
bitmap.c:
- the static buffer was used even when it was too small (but it was
large enough to often work accidentally in depth 16)
- the size of the dynamically allocated buffer was too small
- the sizing info bitmap->PixelBytes was not inititialzed in the bitmap
constructor. It often ended up as 0 for MEMBUFs, so using it in more
places gave more null pointer accesses. (It is per-bitmap, but since
conversion between bitmaps of different depths is not supported (except
from 4 bits by padding to 8), it would work better if it were global.)
main.c:
- depths were rounded down instead of up to a multiple of 8, so PixelBytes
was 1 too small for depths above 8 except 16, 24 and 32.
- PixelBytes was not initialized for 4-bit planar modes. It isn't really
used for frame buffer accesses in these modes, but needs to be 1 in
MEMBUF images.
mouse.c:
- the mouse cursor buffers were too small.
vgl.h:
- PixelBytes was not initialized in the static bitmap constructor. It
should be initialized to the value for the current mode, but that is
impossible in a static constructor. Initialize it to -1 so as to
fail if it is used without further initialization.
All modes that are supposed to be supported now don't crash in
nontrivial tests, and almost work. Missing uses of PixelBytes now
give in-bounds wrong pointers instead of overruns. Misconversions of
bitmaps give multiple miscolored mouse cursors instead of 1 white one,
and similarly for bitmaps copied through a MEMBUF.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Replace all in-tree uses with necessary subset of <sys/{fb,kb,cons}io.h>.
This is also the appropriate fix for exo-tree sources.
Put warnings in <machine/console.h> to discourage use.
November 15th 2000 the warnings will be converted to errors.
January 15th 2001 the <machine/console.h> files will be removed.
It adds new functions and extend some structures and can handle
VESA modes.
- Update the man page.
- Bump the library version number.
(The old version will be added to compat3x.)
