freebsd-skq/lib/libvgl/bitmap.c

318 lines
9.0 KiB
C
Raw Normal View History

/*-
* SPDX-License-Identifier: BSD-3-Clause
*
* Copyright (c) 1991-1997 Søren Schmidt
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer,
* in this position and unchanged.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
2001-09-16 21:35:07 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <sys/types.h>
#include <signal.h>
#include <sys/fbio.h>
#include "vgl.h"
#define min(x, y) (((x) < (y)) ? (x) : (y))
static byte mask[8] = {0xff, 0x7f, 0x3f, 0x1f, 0x0f, 0x07, 0x03, 0x01};
static int color2bit[16] = {0x00000000, 0x00000001, 0x00000100, 0x00000101,
0x00010000, 0x00010001, 0x00010100, 0x00010101,
0x01000000, 0x01000001, 0x01000100, 0x01000101,
0x01010000, 0x01010001, 0x01010100, 0x01010101};
static void
WriteVerticalLine(VGLBitmap *dst, int x, int y, int width, byte *line)
{
int bwidth, i, pos, last, planepos, start_offset, end_offset, offset;
int len;
unsigned int word = 0;
byte *address;
byte *VGLPlane[4];
switch (dst->Type) {
case VIDBUF4:
case VIDBUF4S:
start_offset = (x & 0x07);
end_offset = (x + width) & 0x07;
bwidth = (width + start_offset) / 8;
if (end_offset)
bwidth++;
VGLPlane[0] = VGLBuf;
VGLPlane[1] = VGLPlane[0] + bwidth;
VGLPlane[2] = VGLPlane[1] + bwidth;
VGLPlane[3] = VGLPlane[2] + bwidth;
pos = 0;
planepos = 0;
last = 8 - start_offset;
while (pos < width) {
word = 0;
while (pos < last && pos < width)
word = (word<<1) | color2bit[line[pos++]&0x0f];
VGLPlane[0][planepos] = word;
VGLPlane[1][planepos] = word>>8;
VGLPlane[2][planepos] = word>>16;
VGLPlane[3][planepos] = word>>24;
planepos++;
last += 8;
}
planepos--;
if (end_offset) {
word <<= (8 - end_offset);
VGLPlane[0][planepos] = word;
VGLPlane[1][planepos] = word>>8;
VGLPlane[2][planepos] = word>>16;
VGLPlane[3][planepos] = word>>24;
}
outb(0x3ce, 0x01); outb(0x3cf, 0x00); /* set/reset enable */
outb(0x3ce, 0x08); outb(0x3cf, 0xff); /* bit mask */
for (i=0; i<4; i++) {
outb(0x3c4, 0x02);
outb(0x3c5, 0x01<<i);
outb(0x3ce, 0x04);
outb(0x3cf, i);
pos = VGLAdpInfo.va_line_width*y + x/8;
if (dst->Type == VIDBUF4) {
if (end_offset)
VGLPlane[i][planepos] |= dst->Bitmap[pos+planepos] & mask[end_offset];
if (start_offset)
VGLPlane[i][0] |= dst->Bitmap[pos] & ~mask[start_offset];
bcopy(&VGLPlane[i][0], dst->Bitmap + pos, bwidth);
} else { /* VIDBUF4S */
if (end_offset) {
offset = VGLSetSegment(pos + planepos);
VGLPlane[i][planepos] |= dst->Bitmap[offset] & mask[end_offset];
}
offset = VGLSetSegment(pos);
if (start_offset)
VGLPlane[i][0] |= dst->Bitmap[offset] & ~mask[start_offset];
for (last = bwidth; ; ) {
len = min(VGLAdpInfo.va_window_size - offset, last);
bcopy(&VGLPlane[i][bwidth - last], dst->Bitmap + offset, len);
pos += len;
last -= len;
if (last <= 0)
break;
offset = VGLSetSegment(pos);
}
}
}
break;
case VIDBUF8X:
address = dst->Bitmap + VGLAdpInfo.va_line_width * y + x/4;
for (i=0; i<4; i++) {
outb(0x3c4, 0x02);
outb(0x3c5, 0x01 << ((x + i)%4));
for (planepos=0, pos=i; pos<width; planepos++, pos+=4)
address[planepos] = line[pos];
if ((x + i)%4 == 3)
++address;
}
break;
case VIDBUF8S:
case VIDBUF16S:
case VIDBUF24S:
case VIDBUF32S:
width = width * dst->PixelBytes;
pos = (dst->VXsize * y + x) * dst->PixelBytes;
while (width > 0) {
offset = VGLSetSegment(pos);
i = min(VGLAdpInfo.va_window_size - offset, width);
bcopy(line, dst->Bitmap + offset, i);
line += i;
pos += i;
width -= i;
}
break;
case MEMBUF:
case VIDBUF8:
case VIDBUF16:
case VIDBUF24:
case VIDBUF32:
address = dst->Bitmap + (dst->VXsize * y + x) * dst->PixelBytes;
bcopy(line, address, width * dst->PixelBytes);
break;
default:
;
}
}
int
__VGLBitmapCopy(VGLBitmap *src, int srcx, int srcy,
VGLBitmap *dst, int dstx, int dsty, int width, int hight)
{
byte *buffer, *p;
int mousemerge, srcline, dstline, yend, yextra, ystep;
mousemerge = 0;
if (hight < 0) {
hight = -hight;
mousemerge = (dst == VGLDisplay &&
VGLMouseOverlap(dstx, dsty, width, hight));
if (mousemerge)
buffer = alloca(width*src->PixelBytes);
}
if (srcx>src->VXsize || srcy>src->VYsize
|| dstx>dst->VXsize || dsty>dst->VYsize)
return -1;
if (srcx < 0) {
width=width+srcx; dstx-=srcx; srcx=0;
}
if (srcy < 0) {
hight=hight+srcy; dsty-=srcy; srcy=0;
}
if (dstx < 0) {
width=width+dstx; srcx-=dstx; dstx=0;
}
if (dsty < 0) {
hight=hight+dsty; srcy-=dsty; dsty=0;
}
if (srcx+width > src->VXsize)
width=src->VXsize-srcx;
if (srcy+hight > src->VYsize)
hight=src->VYsize-srcy;
if (dstx+width > dst->VXsize)
width=dst->VXsize-dstx;
if (dsty+hight > dst->VYsize)
hight=dst->VYsize-dsty;
if (width < 0 || hight < 0)
return -1;
yend = srcy + hight;
yextra = 0;
ystep = 1;
if (src->Bitmap == dst->Bitmap && srcy < dsty) {
yend = srcy - 1;
yextra = hight - 1;
ystep = -1;
}
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.
2019-04-21 16:17:35 +00:00
for (srcline = srcy + yextra, dstline = dsty + yextra; srcline != yend;
srcline += ystep, dstline += ystep) {
p = src->Bitmap+(srcline*src->VXsize+srcx)*dst->PixelBytes;
if (mousemerge && VGLMouseOverlap(dstx, dstline, width, 1)) {
bcopy(p, buffer, width*src->PixelBytes);
p = buffer;
VGLMouseMerge(dstx, dstline, width, p);
}
WriteVerticalLine(dst, dstx, dstline, width, p);
}
return 0;
}
int
VGLBitmapCopy(VGLBitmap *src, int srcx, int srcy,
VGLBitmap *dst, int dstx, int dsty, int width, int hight)
{
int error;
if (hight < 0)
return -1;
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.
2019-04-21 16:17:35 +00:00
if (src == VGLDisplay)
src = &VGLVDisplay;
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.
2019-03-27 18:03:34 +00:00
if (src->Type != MEMBUF)
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.
2019-04-21 16:17:35 +00:00
return -1; /* invalid */
if (dst == VGLDisplay) {
VGLMouseFreeze();
__VGLBitmapCopy(src, srcx, srcy, &VGLVDisplay, dstx, dsty, width, hight);
error = __VGLBitmapCopy(src, srcx, srcy, &VGLVDisplay, dstx, dsty,
width, hight);
if (error != 0)
return error;
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.
2019-04-21 16:17:35 +00:00
src = &VGLVDisplay;
srcx = dstx;
srcy = dsty;
} else if (dst->Type != MEMBUF)
return -1; /* invalid */
error = __VGLBitmapCopy(src, srcx, srcy, dst, dstx, dsty, width, -hight);
if (dst == VGLDisplay)
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.
2019-03-27 18:03:34 +00:00
VGLMouseUnFreeze();
return error;
}
VGLBitmap
*VGLBitmapCreate(int type, int xsize, int ysize, byte *bits)
{
VGLBitmap *object;
if (type != MEMBUF)
return NULL;
if (xsize < 0 || ysize < 0)
return NULL;
object = (VGLBitmap *)malloc(sizeof(*object));
if (object == NULL)
return NULL;
object->Type = type;
object->Xsize = xsize;
object->Ysize = ysize;
object->VXsize = xsize;
object->VYsize = ysize;
object->Xorigin = 0;
object->Yorigin = 0;
object->Bitmap = bits;
Fix buffer overruns in modes with color depth more than 8. 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.
2019-03-24 18:57:03 +00:00
object->PixelBytes = VGLDisplay->PixelBytes;
return object;
}
void
VGLBitmapDestroy(VGLBitmap *object)
{
if (object->Bitmap)
free(object->Bitmap);
free(object);
}
int
VGLBitmapAllocateBits(VGLBitmap *object)
{
Fix buffer overruns in modes with color depth more than 8. 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.
2019-03-24 18:57:03 +00:00
object->Bitmap = malloc(object->VXsize*object->VYsize*object->PixelBytes);
if (object->Bitmap == NULL)
return -1;
return 0;
}
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.
2019-04-22 19:31:16 +00:00
void
VGLBitmapCvt(VGLBitmap *src, VGLBitmap *dst)
{
u_long color;
int dstpos, i, pb, size, srcpb, srcpos;
size = src->VXsize * src->VYsize;
srcpb = src->PixelBytes;
if (srcpb <= 0)
srcpb = 1;
pb = dst->PixelBytes;
if (pb == srcpb) {
bcopy(src->Bitmap, dst->Bitmap, size * pb);
return;
}
if (srcpb != 1)
return; /* not supported */
for (srcpos = dstpos = 0; srcpos < size; srcpos++) {
color = VGLrgb332ToNative(src->Bitmap[srcpos]);
for (i = 0; i < pb; i++, color >>= 8)
dst->Bitmap[dstpos++] = color;
}
}