History log of /freebsd-current/lib/libvgl/simple.c
Revision Date Author Comments
# 1d386b48 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 77073527 29-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Oops, r346889 broke showing of the mouse cursor after clearing, by
forgetting to tell the bitmap-copying clearing method to preserve the
cursor.


# c0ce6f7d 29-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Refactor and simplify hiding the mouse cursor and fix bugs caused by
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.


# d6003dd3 26-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Merge __VGLGetXY() back into VGLGetXY(). They were split to simplify
the organization of fixes for the mouse cursor, but after optimizations
VGLGetXY() automatically avoids the mouse cursor.


# 5800d10f 26-Apr-2019 Bruce Evans <bde@FreeBSD.org>

In VGLClear(), check for the overlap of the mouse cursor in the whole
display, not just in the unpanned top left corner. This currently
makes no difference since the kernel erroneously doesn't allow moving
the cursor completely outside of the unpanned corner.


# ea0a9905 26-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Fix the only known remaining (libvgl) bug for 24-bit modes, and enable
support for 24-bit modes.

The non-segmented case has worked for a long time, but the segmented
case could never have worked since 24-bit accesses may cross a window
boundary but the window was not changed in the middle of the specialized
24-bit accesses for writing a single pixel.


# c7432537 24-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Refactor mouse freezing and fix some minor bugs.

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.


# a93ca07a 22-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Fix mouse cursor coloring in depths > 8 (previously, a hack that only
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.


# 1fa51420 21-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Use a shadow buffer and never read from the frame buffer. Remove large slow
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.


# e848f3d1 21-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Fix missing restoring of the mouse cursor position, the border color and the
blank state after a screen switch.


# 80b4b86e 20-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Make libvgl mostly work without superuser privilege in direct modes by
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.


# 9db56319 16-Apr-2019 Bruce Evans <bde@FreeBSD.org>

Fix a variable name in r346215. Clearing of the right of the screen was
broken, except it worked accidentally in most cases where the virtual
screen is larger than the physical screen.


# 5cf92d7a 14-Apr-2019 Bruce Evans <bde@FreeBSD.org>

For writing and reading single pixels, avoid some pessimizations for
depths > 8. Add some smaller optimizations for these depths. Use a
more generic method for all depths >= 8, although this gives tiny
pessimizations for these depths.

For clearing the whole frame buffer, avoid the same pessimizations
for depths > 8. Add some larger optimizations for these depths. Use
an even more generic method for all depths >= 8 to give the optimizations
for depths > 8 and a tiny pessimization for depth 8.

The main pessimization was that old versions of bcopy() copy 1 byte at a
time for all trailing bytes. (i386 still does this. amd64 now pessimizzes
large sizes instead of small ones if the CPU supports ERMS. dev/fb gets
this wrong by mostly not using the bcopy() family or the technically correct
bus space functions but by mostly copying 2 bytes at a time using an
unoptimized loop without even volatile declarations to prevent the compiler
rewriting it.)

The sizes here are 1, 2, 3 or 4 bytes, so depths 9-16 were up to twice as
slow as necessary and depths 17-24 were up to 3 times slower than necessary.
Fix this (except depths 17-24 are still up to 2 times slower than necessary)
by using (builtin) memcpy() instead of bcopy() and reorganizing so that the
complier can see the small constant sizes. Reduce special cases while
reorganizing although this is slightly slower than adding special cases.
The compiler inlining (and even -O2 vs -O0) makes little difference compared
with reducing the number of accesses except on modern hardware it gives a
small improvement.

Clearing was also pessimized mainly by the extra accesses. Fix it quite
differently by creating a MEMBUF containing 1 line (in fast memory using
a slow method) and copying this. This is only slightly slower than reducing
everything to efficient memset()s and bcopy()s, but simpler, especially
for the segmented case. This works for planar modes too, but don't use it
then since the old method was actually optimal for planar modes (it works
by moving the slow i/o instructions out of inner loops), while for direct
modes the slow instructions were all in the invisible inner loop in bcopy().

Use htole32() and le32toh() and some type puns instead of unoptimized
functions for converting colors. This optimization is mostly in the noise.
libvgl is only supported on x86, so it could hard-code the assumption that
the byte order is le32, but the old conversion functions didn't hard-code
this.


# 5ee94e99 28-Mar-2019 Bruce Evans <bde@FreeBSD.org>

Fix VGLLine() in depths > 8.

It started truncating its color arg to 8 bits using plot() in r229415.
The version in r229415 is also more than 3 times slower in segmented
modes, by doing more syscalls to move the window.


# baca0ce6 27-Mar-2019 Bruce Evans <bde@FreeBSD.org>

Fix VGLGetXY(), VGLSetXY() and VGLClear() for MEMBUFs in depths > 8.

This depends on PixelBytes being properly initialized, which it is for
all bitmaps constructed by libvgl except mouse cursor bitmaps.


# fa68d9b9 28-Mar-2019 Bruce Evans <bde@FreeBSD.org>

Oops, r345496 got the pointer args backwards for bcopy() in VGLClear for
segmented modes.

Also fix some style bugs in the 2 changed lines. libvgl uses a very non-KNF
style with 2-column indentation with no tabs except for regressions.


# 014ddcbc 27-Mar-2019 Bruce Evans <bde@FreeBSD.org>

Fix accessing pixels under the mouse cursor:

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.


# dac776fd 25-Mar-2019 Bruce Evans <bde@FreeBSD.org>

Fix another type of buffer overrun for segmented modes. The buffer index
was not taken modulo the window size in VGLClear().

Segmented modes also need a kernel fix to almost work. The ioctl to set
the window origin is broken.

These bugs are rarely problems since non-VESA modes only need
segmentation to support multiple pages but libvgl doesn't support
multiple pages and treats these modes as non-segmented, and VESA modes
are usually mapped linearly except on old hardware so they really are
non-segmented.


# 1382e2a9 24-Mar-2019 Bruce Evans <bde@FreeBSD.org>

Fix reading of pixels in (4 and 8-plane) planar modes.

There seems to be no alternative to reading each plane independently using
3 slow i/o's per plane (this delivers 8 nearby pixels, but we don't buffer
the results so run 8 times slower than necessary.

All the code for this was there, but it was ifdefed out and replaced by
simpler code that cannot work in planar modes. The ifdefed out code
was correct except it was missing a volatile declaration, so compilers
optimized the multiple dummy reads in it to a single read.


# 5e53a4f9 25-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

lib: further adoption of SPDX licensing ID tags.

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.


# bf3f9db6 07-Jan-2012 Ulrich Spörlein <uqs@FreeBSD.org>

Convert files to UTF-8 and add some copyright markers where missing.


# 83057baf 04-Jan-2012 Pedro F. Giffuni <pfg@FreeBSD.org>

Quiet down clang -Werror.

Reported by: Pawel Worach
Approved by: jhb (mentor)


# 4c995944 03-Jan-2012 Pedro F. Giffuni <pfg@FreeBSD.org>

Integrate the line drawing algorithm from the book "Graphic Gems 1".

http://www.graphicsgems.org/

At the time it claimed to be 3-4 times faster than the traditional
algorithm.

PR: 18769
Approved by: jhb (mentor)
MFC after: 2 weeks


# a7d5f7eb 19-Oct-2010 Jamie Gritton <jamie@FreeBSD.org>

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.


# e7032b4c 04-Oct-2010 Dimitry Andric <dim@FreeBSD.org>

Change libvgl's set4pixels() and set2lines() functions from plain
'inline' to 'static inline'. Otherwise, a C99 compiler (such as clang)
will output an undefined symbol for those functions in the resulting
object file. (Even gcc will do this, when you use "-std=c99".)

This should fix the "undefined reference to `set4pixels'" errors that
some people were seeing during ports building, when their world was
compiled with clang.

Approved by: rpaulo (mentor)


# fe0506d7 09-Mar-2010 Marcel Moolenaar <marcel@FreeBSD.org>

Create the altix project branch. The altix project will add support
for the SGI Altix 350 to FreeBSD/ia64. The hardware used for porting
is a two-module system, consisting of a base compute module and a
CPU expansion module. SGI's NUMAFlex architecture can be an excellent
platform to test CPU affinity and NUMA-aware features in FreeBSD.


# d7f03759 19-Oct-2008 Ulf Lilleengen <lulf@FreeBSD.org>

- Import the HEAD csup code which is the basis for the cvsmode work.


# 21dc7d4f 02-Jun-2002 Jens Schweikhardt <schweikh@FreeBSD.org>

Fix typo in the BSD copyright: s/withough/without/

Spotted and suggested by: des
MFC after: 3 weeks


# e67f5b9f 16-Sep-2001 Matthew Dillon <dillon@FreeBSD.org>

Implement __FBSDID()


# 933d455f 13-Jan-2001 Nicolas Souchu <nsouch@FreeBSD.org>

Add Truecolor 16 and 32bits support. Note that 24bits modes are not
supported since it's not easy to put 3 bytes accross 64Kb windows
of memory. This should not be such a problem with linear framebuffers.

There is no major interface modification except that the color type
becomes u_long instead of byte. So one just need to recompile his
application.

Approved by: Soren Schmidt <sos@freebsd.dk>


# 00d25f51 08-Oct-2000 Poul-Henning Kamp <phk@FreeBSD.org>

Initiate deorbit burn sequence for <machine/console.h>.

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.


# 5acf51ea 08-Nov-1999 Kazutaka YOKOTA <yokota@FreeBSD.org>

- This is the new version of libvgl jointly developed by sos and I.
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.)


# 7f3dea24 27-Aug-1999 Peter Wemm <peter@FreeBSD.org>

$Id$ -> $FreeBSD$


# 5e7a62b2 21-Aug-1999 Kazutaka YOKOTA <yokota@FreeBSD.org>

Assorted bug fixes.

keyboard.c
- Call tcsetattr() in VGLKeyboardEnd() to restore tty, only when
tty attributes have been previously saved.
PR: misc/9524
Submitted by: Katusyuki 'kei' Maeda (kei@nanet.co.jp)
- Set up the tty raw mode correctly.

main.c
- Restore VESA_800x600 raster text mode correctly in VGLEnd().
Submitted by: des

text.c
- Allocate the correct size of a font buffer in VGLSetFontFile().
I forgot the submitter ;-(

simple.c, bitmap.c
- Fix address calculation for the VGA mode X in VGLGetXY() and
VGLBitmapCopy().
- Fix typo (dsty -> dstx) in __VGLBitmapCopy().

Reviewed by: sos


# 9a57b7d2 17-Aug-1997 Søren Schmidt <sos@FreeBSD.org>

First import of my little "video graphic library".

See the manpage vgl.3 for more info.

A little example will follow shortly.