: Yeah Greg, why don't you use some sort of XORmap ? I understand it
: consumes lots of memory but it would allow faster screen refresh (try
: clicking on background window, do it once again and again and you'll
: notice flicker when former background window gets redrawn layer by
: layer). I guess you already use some memory for framebuffer so you could
: do xormapping in that memory before outputting it to the screen.
I'm working on other paint mechanisms for slow systems. the
current mechanism works great on faster systems, and looks like the newer
window move algorithms that MS took so damn long to write.
I am planning on a major architecture change to the Micro-Windows
graphics engine, in regards to device contexts. Currently, there is no support
whatever for off-screen (memory bitmap) drawing. That's why I said earlier
that we didn't need bitblt yet. I'm planning on adding off-screen drawing
that will allow background images to be painted and then blt'd to the real screen.
However, this won't solve your paint speed problem... my current solution
suspends all non-active window drawing (except background erase) while the user
is moving the mouse. Once that stops, the invalid areas are redrawn. What is needed
is a interruptible action such that during this repaint, if the user moves the mouse,
it is interrupted, and the active window is moved immediately. If all this was done
to a background bitmap, then the user would perceive extreme slowness while
that was being done. That's the big problem with small slow systems, that is, they're
too slow to move many pixels, period.
Finally, I'm going to implement an XOR-based window rectangle that will be
drawn when the user moves a window, much like old windows 3.x. This will make
the screen look better for slower systems, like ELKS. The memory-consuming
XORmap that you're suggesting won't work on ELKS cause we've got a hard 64k
data seg limit, unless we want to start using far pointers, etc.
Greg
