<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in bitmap.c</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>1d386b48 - Remove $FreeBSD$: one-line .c pattern</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#1d386b48</link>
        <description>Remove $FreeBSD$: one-line .c patternRemove /^[\s*]*__FBSDID\(&quot;\$FreeBSD\$&quot;\);?\s*\n/

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Wed, 16 Aug 2023 17:54:42 +0000</pubDate>
        <dc:creator>Warner Losh &lt;imp@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>2f5cff37 - Fix copying planar bitmaps when the horizontal start and end are both not</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#2f5cff37</link>
        <description>Fix copying planar bitmaps when the horizontal start and end are both notmultiples of 8.  Then the misaligned pixels at the end were not copied.Clean up variable misuse related to this bug.  The width in bytes wasfirst calculated correctly and used to do complicated reblockingcorrectly, but it was stored in an unrelated scratch variable and laterrecalculated with an off-by-1-error, so the last byte (times 4 planes)in the intermediate copy was not copied.This doubly-misaligned case is especially slow.  Misalignment complicatesthe reblocking, and each misaligment requires a read before write, and thisread is still not done from the shadow buffer.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Fri, 03 May 2019 13:06:46 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>71819202 - Fix an off-by-1 error for copying overlapping bitmaps in r346416.  For</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#71819202</link>
        <description>Fix an off-by-1 error for copying overlapping bitmaps in r346416.  Fornonzero height, the first line in the original order was not copied, andfor zero height, garbage lines before the first were copied until a crashoccurred.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Fri, 26 Apr 2019 13:04:10 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>a07067ea - Avoid hiding and unhiding the mouse cursor when copying bitmaps to the</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#a07067ea</link>
        <description>Avoid hiding and unhiding the mouse cursor when copying bitmaps to thescreen.  Instead, copy a merged bitmap 1 line at a time.This fixes flashing of the cursor and is faster in all modes (especiallyin planar modes).

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Wed, 24 Apr 2019 16:03:35 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>c7432537 - Refactor mouse freezing and fix some minor bugs.</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#c7432537</link>
        <description>Refactor mouse freezing and fix some minor bugs.VGLMouseFreeze() now only defers mouse signals and leaves it to higherlevels to hide and unhide the mouse cursor if necessary.  (It is nevernecessary, but is done to simplify the implementation.  It is slow andflashes the cursor.  It is still done for copying bitmaps and clearing.)VGLMouseUnFreeze() now only undoes 1 level of freezing.  Its oldoptimization to reduce mouse redrawing is too hard to do with unhidingin higher levels, and its undoing of multiple levels was a historicalmistake.VGLMouseOverlap() determines if a region overlaps the (full) mouse region.VGLMouseFreezeXY() is the freezing and a precise overlap check combinedfor the special case of writing a single pixel.  This is the single-pixelcase of the old VGLMouseFreeze() with cleanups.Fixes:- check in more cases that the application didn&apos;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&apos;t spell the #defined values for VGLMouseShown as 0, 1 or boolean.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Wed, 24 Apr 2019 15:35:29 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>a93ca07a - Fix mouse cursor coloring in depths &gt; 8 (previously, a hack that only</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#a93ca07a</link>
        <description>Fix mouse cursor coloring in depths &gt; 8 (previously, a hack that onlyworked right for white interiors and black borders was used).  Advertisethis by changing the default colors to a red interior and a whiteborder (the same as the kernel default).  Add undocumented env variablesfor changing these colors.  Also change to the larger and better-shaped16x10 cursor sometimes used in the kernel.  The kernel choice isfancier, but libvgl is closer to supporting the larger cursors neededin newer modes.The (n)and-or logic for the cursor doesn&apos;t work right for more than 2colors.  The (n)and part only masks out all color bits for the pixelunder the cursor when all bits are set in the And mask.  With morecomplicated logic, the non-masked bits could be used to implementtranslucent cursors, but they actually just gave strange colors(especially in packed and planar modes where the bits are indirectthrough 1 or 2 palettes so it is hard to predict the final color).They also gave a bug for writing pixels under the cursor.  Thenon-masked bits under the cursor were not combined in this case.Drop support for combining with bits under the cursor by making any nonzerovalue in the And mask mean all bits set.Convert the Or mask (which is represented as a half-initialized 256-colorbitmap) 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 finalbitmap has more than 256 colors.  The conversion of colors is not veryefficient, so convert at initialization time.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Mon, 22 Apr 2019 19:31:16 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>1fa51420 - Use a shadow buffer and never read from the frame buffer.  Remove large slow</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#1fa51420</link>
        <description>Use a shadow buffer and never read from the frame buffer.  Remove large slowcode for reading from the frame buffer.Reading from the frame buffer is usually much slower than writing tothe frame buffer.  Typically 10 to 100 times slower.  It old modes,it takes many more PIOs, and in newer modes with no PIOs writes areoften write-combined while reads remain uncached.Reading from the frame buffer is not very common, so this change doesn&apos;tgive speedups of 10 to 100 times.  My main test case is a floodfill()function that reads about as many pixels as it writes.  The speedupsare typically a factor of 2 to 4.Duplicating writes to the shadow buffer is slower when no reads from theframe buffer are done, but reads are often done for the pixels under themouse cursor, and doing these reads from the shadow buffer more thancompensates for the overhead of writing the shadow buffer in at least theslower modes.  Management of the mouse cursor also becomes simpler.The shadow buffer doesn&apos;t take any extra memory, except twice as muchin old 4-plane modes.  A buffer for holding a copy of the frame bufferwas allocated up front for use in the screen switching signal handler.This wasn&apos;t changed when the handler was made async-signal safe.  Usethe same buffer the shadow (but make it twice as large in the 4-planemodes), and remove large special code for writing it as well as largespecial code for reading ut.  It used to have a rawer format in the4-plane modes.  Now it has a bitmap format which takes twice as muchmemory but can be written almost as fast without special code.VIDBUFs that are not the whole frame buffer were never supported, and thechange depends on this.  Check for invalid VIDBUFs in some places and donothing.  The removed code did something not so good.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Sun, 21 Apr 2019 16:17:35 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>1e4abf1d - Fix copying of overlapping bitmaps.  The cases of copying within the</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#1e4abf1d</link>
        <description>Fix copying of overlapping bitmaps.  The cases of copying within thescreen bitmap and within a single MEMBUF were broken when first sourceline is before the first destination line and the sub-bitmaps overlap.The fix just copies horizontal lines in reverse order when the firstsource line is before the first destination line.  This switchesdirections unnecessarily in some cases, but the switch is about asfast as doing a precise detection of overlaps.  When the first linesare the same, there can be undetected overlap in the horizontaldirection.  The old code already handles this mostly accidentally byusing bcopy() for MEMBUFs and by copying through a temporary bufferfor the screen bitmap although the latter is sub-optimal in directmodes.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Fri, 19 Apr 2019 20:29:49 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>b8e788b6 - Fix copying of MEMBUFs to MEMBUFs.  This case was implemented by using</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#b8e788b6</link>
        <description>Fix copying of MEMBUFs to MEMBUFs.  This case was implemented by usingthe same code as the VIDBUF8 case, so it only worked for depths &lt;= 8.The 2 directions for copying between VIDBUFs and MEMBUFs worked by usinga Read/Write organization which makes the destination a VIDBUF so theMEMBUF case was not reached, and the VIDBUF cases have already been fixed.Fix this by removing &quot;optimizations&quot; for the VIDBUF8 case so that theMEMBUF case can fall through to the general (non-segmented) case.  Theoptimizations were to duplicate code for the VIDBUF8 case so as toavoid 2 multiplications by 1 at runtime.  This optimization is not usefulsince the multiplications are not in the inner loop.Remove the same &quot;optimization&quot; for the VIDBUF8S case.  It was even lessuseful there since it duplicated more to do relatively less.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Mon, 08 Apr 2019 04:54:15 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>014ddcbc - Fix accessing pixels under the mouse cursor:</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#014ddcbc</link>
        <description>Fix accessing pixels under the mouse cursor:Reading of single pixels didn&apos;t look under the cursor.Copying of 1x1 bitmaps didn&apos;t look under the cursor for either readingor writing.Copying of larger bitmaps looked under the cursor for at most thedestination.Copying of larger bitmaps looked under a garbage cursor (for the Displaybitmap) when the destination is a MEMBUF.  The results are not used, sothis only wasted time and flickered the cursor.Writing of single pixels looked under a garbage cursor for MEMBUFdestinations, as above except this clobbered the current cursor anddidn&apos;t update the MEMBUF.  Writing of single pixels is not implementedyet in depths &gt; 8.  Otherwise, writing of single pixels worked.  It wasthe 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 freezingfunction to control the function.  Also clear the top 8 bits so thatapplications can&apos;t clobber the control bits or create 256 aliases forevery 24-bit pixel value in depth 32.Races fixed:Showing and hiding the cursor only tried to avoid races with the mouseevent signal handler for internal operations.  There are still manyshorter races from not using volatile or sig_atomic_t for the variableto control this.  This variable also controls freezes, and has morecomplicated states than before.The internal operation of unfreezing the cursor opened a race windowby unsetting the signal/freeze variable before showing the cursor.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Wed, 27 Mar 2019 18:03:34 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>aa1ce985 - Fix copying of bitmaps in depths &gt; 8.  This fix is complete, except different</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#aa1ce985</link>
        <description>Fix copying of bitmaps in depths &gt; 8.  This fix is complete, except differentdepths for the source and target are not supported.  The bits for highernumbered planes (mostly for red) were either not copied or were copied tolower numbered planes for nearby pixels.Quick fix for creation of mouse cursor bitmaps in all depths.   This fix isonly complete for the default lightwhite cursor with a black frame.Even the lightwhite and black colors are hard to find.  The templatesuse 0xff for lightwhite, but that means brightblue in the simplest mode(Truecolor depth 24).  Other modes are even more complicated -- they aresingly or doubly indirect throught palette(s) and changing of the palettesby applications is supported.Details:Replicate the template value for Truecolor modes to fill out the targetdepth (and more for depths not a multiple of 8).  Do this for everydrawing of the cursor so that it sort of works for mouse cursor bitmapsset by applications.Use 0xf for lightwhite in most other modes.  Only do this for thedefault cursor so that it doesn&apos;t affect mouse cursor bitmaps set byapplications.  0xf mostly works because it was originally for CGAlightwhite and is emulated using 1 or 2 indirections on EGA and VGA.0x3f (EGA white) and 0xff (VGA black) direct palette indexes mostlydon&apos;t work since backwards compatibility inhibits or prevents themrepresenting lightwhite.  But 0x3f (EGA white) must be used for mode37 (VGA_MODEX) (320x240x8 V) since this mode is closer to EGA than VGA.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Wed, 27 Mar 2019 08:02:55 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>fbc6daa1 - Fix buffer overruns in modes with color depth more than 8.</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#fbc6daa1</link>
        <description>Fix buffer overruns in modes with color depth more than 8.Support for 16-bit and 32-bit Truecolor modes was supposed to becomplete in r70991 of main.c and in nearby revisions for other files, butit was broken by the overruns in most cases (all cases were the mouseis enabled, and most cases where bitmaps are used).  r70991 alsouninintentionally added support for depths 9-15, 17-23 and 25-31.Depth 24 was more obviously broken and its support is ifdefed out.  Inthe other ranges, only depth 15 is common.  It was broken by bufferoverruns 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-&gt;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&apos;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&apos;t crash innontrivial tests, and almost work.  Missing uses of PixelBytes nowgive in-bounds wrong pointers instead of overruns.  Misconversions ofbitmaps give multiple miscolored mouse cursors instead of 1 white one,and similarly for bitmaps copied through a MEMBUF.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Sun, 24 Mar 2019 18:57:03 +0000</pubDate>
        <dc:creator>Bruce Evans &lt;bde@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>5e53a4f9 - lib: further adoption of SPDX licensing ID tags.</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#5e53a4f9</link>
        <description>lib: further adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 2-Clause license, however the tool Iwas using mis-identified many licenses so this was mostly a manual - errorprone - task.The Software Package Data Exchange (SPDX) group provides a specificationto make it easier for automated tools to detect and summarize well knownopensource licenses. We are gradually adopting the specification, notingthat the tags are considered only advisory and do not, in any way,superceed or replace the license texts.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Sun, 26 Nov 2017 02:00:33 +0000</pubDate>
        <dc:creator>Pedro F. Giffuni &lt;pfg@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>bf3f9db6 - Convert files to UTF-8 and add some copyright markers where missing.</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#bf3f9db6</link>
        <description>Convert files to UTF-8 and add some copyright markers where missing.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Sat, 07 Jan 2012 16:13:56 +0000</pubDate>
        <dc:creator>Ulrich Sp&#246;rlein &lt;uqs@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>21dc7d4f - Fix typo in the BSD copyright: s/withough/without/</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#21dc7d4f</link>
        <description>Fix typo in the BSD copyright: s/withough/without/Spotted and suggested by:	desMFC after:	3 weeks

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Sun, 02 Jun 2002 20:05:59 +0000</pubDate>
        <dc:creator>Jens Schweikhardt &lt;schweikh@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>a96d3de6 - Fix syntax errors (labels with no statement following).</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#a96d3de6</link>
        <description>Fix syntax errors (labels with no statement following).

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Thu, 30 May 2002 21:03:02 +0000</pubDate>
        <dc:creator>Garrett Wollman &lt;wollman@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>e67f5b9f - Implement __FBSDID()</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#e67f5b9f</link>
        <description>Implement __FBSDID()

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Sun, 16 Sep 2001 21:35:07 +0000</pubDate>
        <dc:creator>Matthew Dillon &lt;dillon@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>933d455f - Add Truecolor 16 and 32bits support. Note that 24bits modes are not</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#933d455f</link>
        <description>Add Truecolor 16 and 32bits support. Note that 24bits modes are notsupported since it&apos;s not easy to put 3 bytes accross 64Kb windowsof memory. This should not be such a problem with linear framebuffers.There is no major interface modification except that the color typebecomes u_long instead of byte. So one just need to recompile hisapplication.Approved by:	Soren Schmidt &lt;sos@freebsd.dk&gt;

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Sat, 13 Jan 2001 11:30:17 +0000</pubDate>
        <dc:creator>Nicolas Souchu &lt;nsouch@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>00d25f51 - Initiate deorbit burn sequence for &lt;machine/console.h&gt;.</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#00d25f51</link>
        <description>Initiate deorbit burn sequence for &lt;machine/console.h&gt;.Replace all in-tree uses with necessary subset of &lt;sys/{fb,kb,cons}io.h&gt;.This is also the appropriate fix for exo-tree sources.Put warnings in &lt;machine/console.h&gt; to discourage use.November 15th 2000 the warnings will be converted to errors.January 15th 2001 the &lt;machine/console.h&gt; files will be removed.

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Sun, 08 Oct 2000 21:34:00 +0000</pubDate>
        <dc:creator>Poul-Henning Kamp &lt;phk@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>5acf51ea - - This is the new version of libvgl jointly developed by sos and I.</title>
        <link>http://172.16.0.5:8080/history/freebsd-14.2/lib/libvgl/bitmap.c#5acf51ea</link>
        <description>- 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.)

            List of files:
            /freebsd-14.2/lib/libvgl/bitmap.c</description>
        <pubDate>Mon, 08 Nov 1999 11:37:46 +0000</pubDate>
        <dc:creator>Kazutaka YOKOTA &lt;yokota@FreeBSD.org&gt;</dc:creator>
    </item>
</channel>
</rss>
