nanogui: Thread: Microwindows v0.86

I have posted an update v0.86 to Microwindows/nano-X at
    ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.86.tar.gz

This version completes a major effort, that of implementing off-screen
drawing,
as well as screen-to-screen blitting.  The screen driver interface had to
change
to accomodate this, and I had to rewrite all the screen drivers.  In
addition, the
blitting routines were written for 1, 2, 4, 8, 16 and 32bpp linear
framebuffer devices,
as well as the 16 color 4 planes vga (this was a royal pain...)  The
blitting
uses a clipping region traversal algorithm so that blitting is always high
speed,
even when the destination window is partly obscured.

This release also auto-detects most Linux framebuffer implementations, and
should have a compiled in driver for it.


In addition I have posted Linux, ELKS and MSDOS binaries, as well as
screenshots
for those that don't have the time:

    ftp://microwindows.censoft.com/pub/microwindows/SreenShots
    ftp://microwindows.censoft.com/pub/microwindows/LinuxExamples
    ftp://microwindows.censoft.com/pub/microwindows/ElksExamples
    ftp://microwindows.censoft.com/pub/microwindows/DosExamples

The standard Microwindows demo is now a graphical terminal emulator, mterm.
(No,
it doesn't run vi yet, and it doesn't repaint it's screen contents, but it
will ;-)  This demo
requires screen-to-screen blitting for scrolling.  The 3d graphics demo now
uses
offscreen blitting to enhance (read no flicker) the display.  Check it out.

There is also some experimental full-blown region handling code included,
which
uses X11's y-x banding region algorithms.  (This stuff is truly for those
with
extra time and brains).  It is currently not compiled in, but can be
included
by replacing devclip.c with devclip2.c.  In the next release, arbitrary
multi-rectangle
clipping regions will be available.  I also plan on implementing separate
clip regions
from update regions for windows, with the system computing the update region
as a subset of the clip region.  Anyway, this sophisticated region handling
is
required for smart window painting as well as higher end graphics
primitives.
Eventually, this will also allow separate source and destination clipping
for bitblit
operations.  Only destination clipping is working now.

The next release will have a reorganized directory structure, allowing
separate
development of nano-X, widgets, core engine, and microwindows.  I plan
on moving the whole thing to a CVS soon.  BTW, Microwindows now supports
three processor families, according to reports emailed me.  We've got i386,
8086,
MIPS Vr41xx, and ARM families running ;-)


Following is a summary of the ChangeLog:

Version 0.86 - 28th October 1999 - ####@####.####
 * merged framebuffer, elks and msdos vga 16 color 4 planes drivers
 * wrote vga bitbit routines (a herculean effort)
 * optimized bitblit by traversing window clip region
 * added experimental multi-rectangle dynamically allocated regions
 * wrote scrolling terminal emulator demo for microwindows
 * added WM_FDINPUT msg, WndRegisterFdInput call for terminal emulator
 * changed SCREENINFO struct, removed black/white, added bpp, planes
 * added offscreen (memory DC) drawing to microwindows
 * added BitBlt, CreateCompatibleBitmap, CreateCompatibleDC, DeleteDC
 * retired BOGL library, must use new interface for blitting
 * converted framebuffer, svgalib, elks and msdos screen drivers
 * (we need blit routines for herc and svgalib still)
 * major screen driver interface change, old drivers not compatible

Greg

I saw one slight bug in MicroWin microblt program...when dragging a
window, the windows w/o focus do not seem to have their window updated.
Maybe this is just a bug in micrblt as I see that microwin does not have
this problem.

------------------------------------------------------------------
"If a frog had wings, he wouldn't bump his a$$ when he hopped!"
                          - Red Foreman of That '70s Show

On Thu, 28 Oct 1999, Greg Haerr wrote:

> I have posted an update v0.86 to Microwindows/nano-X at
>     ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.86.tar.gz
> 
> This version completes a major effort, that of implementing off-screen
> drawing,
> as well as screen-to-screen blitting.  The screen driver interface had to
> change
> to accomodate this, and I had to rewrite all the screen drivers.  In
> addition, the
> blitting routines were written for 1, 2, 4, 8, 16 and 32bpp linear
> framebuffer devices,
> as well as the 16 color 4 planes vga (this was a royal pain...)  The
> blitting
> uses a clipping region traversal algorithm so that blitting is always high
> speed,
> even when the destination window is partly obscured.
> 
> This release also auto-detects most Linux framebuffer implementations, and
> should have a compiled in driver for it.
> 
> 
> In addition I have posted Linux, ELKS and MSDOS binaries, as well as
> screenshots
> for those that don't have the time:
> 
>     ftp://microwindows.censoft.com/pub/microwindows/SreenShots
>     ftp://microwindows.censoft.com/pub/microwindows/LinuxExamples
>     ftp://microwindows.censoft.com/pub/microwindows/ElksExamples
>     ftp://microwindows.censoft.com/pub/microwindows/DosExamples
> 
> The standard Microwindows demo is now a graphical terminal emulator, mterm.
> (No,
> it doesn't run vi yet, and it doesn't repaint it's screen contents, but it
> will ;-)  This demo
> requires screen-to-screen blitting for scrolling.  The 3d graphics demo now
> uses
> offscreen blitting to enhance (read no flicker) the display.  Check it out.
> 
> There is also some experimental full-blown region handling code included,
> which
> uses X11's y-x banding region algorithms.  (This stuff is truly for those
> with
> extra time and brains).  It is currently not compiled in, but can be
> included
> by replacing devclip.c with devclip2.c.  In the next release, arbitrary
> multi-rectangle
> clipping regions will be available.  I also plan on implementing separate
> clip regions
> from update regions for windows, with the system computing the update region
> as a subset of the clip region.  Anyway, this sophisticated region handling
> is
> required for smart window painting as well as higher end graphics
> primitives.
> Eventually, this will also allow separate source and destination clipping
> for bitblit
> operations.  Only destination clipping is working now.
> 
> The next release will have a reorganized directory structure, allowing
> separate
> development of nano-X, widgets, core engine, and microwindows.  I plan
> on moving the whole thing to a CVS soon.  BTW, Microwindows now supports
> three processor families, according to reports emailed me.  We've got i386,
> 8086,
> MIPS Vr41xx, and ARM families running ;-)
> 
> 
> Following is a summary of the ChangeLog:
> 
> Version 0.86 - 28th October 1999 - ####@####.####
>  * merged framebuffer, elks and msdos vga 16 color 4 planes drivers
>  * wrote vga bitbit routines (a herculean effort)
>  * optimized bitblit by traversing window clip region
>  * added experimental multi-rectangle dynamically allocated regions
>  * wrote scrolling terminal emulator demo for microwindows
>  * added WM_FDINPUT msg, WndRegisterFdInput call for terminal emulator
>  * changed SCREENINFO struct, removed black/white, added bpp, planes
>  * added offscreen (memory DC) drawing to microwindows
>  * added BitBlt, CreateCompatibleBitmap, CreateCompatibleDC, DeleteDC
>  * retired BOGL library, must use new interface for blitting
>  * converted framebuffer, svgalib, elks and msdos screen drivers
>  * (we need blit routines for herc and svgalib still)
>  * major screen driver interface change, old drivers not compatible
> 
> Greg
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

On Thursday, October 28, 1999 9:55 PM, Louis P. Santillan ####@####.#### wrote:
: I saw one slight bug in MicroWin microblt program...when dragging a
: window, the windows w/o focus do not seem to have their window updated.
: Maybe this is just a bug in micrblt as I see that microwin does not have
: this problem.

Louis - thanks for the input.  I assume you mean that the window update's never
occured, because the default drag algorithm is to just erase background during
dragging, and repaint after the drag activity is completed, so that the drag operates
faster.  In any case, I'll check it out.  [I assume this was the MSDOS example, right?]

Greg

: I saw one slight bug in MicroWin microblt program...when dragging a
: window, the windows w/o focus do not seem to have their window updated.
: Maybe this is just a bug in micrblt as I see that microwin does not have
: this problem.
: 
Louis - I have checked into this and there is a redraw problem in windows
that used memory DC's, right after moving the window.  Thanks, I'll fix it.

Greg