nanogui: nano-X 0.6
Subject:
RE: nano-X 0.6
From:
Greg Haerr ####@####.####
Date:
25 Jun 1999 18:42:54 -0000
Message-Id: <01BEBF07.DB2369C0.greg@censoft.com>
: I just tried microwindows 0.81 and it worked first time (apart from the
: math.h thing). I don't know what changed to make it work, but it's pretty
: impressive.
I've fixed the math.h problem for the next cut.
:
: A few points:
:
: * Giving focus to a window doesn't bring it to the top, which means that
: the height placement rules are effectively hard wired because the
: depth of a window never changes.
I've got that coded temporarliy for now. I wanted to test the window
move algorithm when painting low-zorder windows. Mousedown on the
non-caption are to bring it to top. (this is a one line change in windefw.c)
: * The redrawing algorithm is so slow (seconds on a Pentium 150, presumably
: minutes on an 8088) that the current window movement algorithm isn't
: really ideal (ie. it looks ugly when you grab a window and move it around
: and it leaves trails which take a second to disappear). The "slow window
: move algorithm" seems to be faster than the "fast window move algorithm"
: and doesn't leave as many ugly trails.
The current algo is close to MS's for faster machine window repaint.
I'll write one that draws an XOR frame and it'll appear far better on slower
machines.
: * It would look better (and possibly be more efficient, depending on how
: you implement it) if the drawing of windows was Z sorted from back to
: front, instead of just basing the clipping on Z order (at the moment, the
: background is drawn last, which doesn't look very nice).
Yes, I agree. Again, I was just trying to get the dang thing out.
This whole thing was written at home over the last two weeks. My next
plan is to start optimizing. In another email I noted that what I really
need is update regions, and then only the portion that's effected is redrawn,
unlike now, where everything gets redrawn. (the wallpaper flicker
is ugly, I agree.)
Also, when I implement off-screen drawing, the desktop window
can avoid the background flicker that you see now. Another way is to
add application-level clipping, so that it could clip the background erase
to the not-intersection of the background wallpaper. That's coming too..
: * The 3D app revealed another problem with the "client compiled into the
: server" model that I hadn't thought of before- if a client wants to use
: 100% of the processor time, the server doesn't have any chance to do
: things like moving the mouse until the client asks the server to do
: something. This reveals this in the very wierd mouse movement behaviour
: over the 3D window, as the server can only move the mouse whenever the
: application does enough processing to ask it to draw another frame.
Humm. Let's keep thinking about this. This will become
a bigger issue on slower machines, also.
: * The animated buttons don't seem to look quite right (the bottom and
: right hand sides of the button should move too, right?).
Not in the MS model ;-) That button is 100% MS compatible....
I'm not suggesting that that's the only button, though, but I wanted to write
at least one 3d custom control.
: * It looks and behaves almost exactly like Windows (a bad thing in my book ;).
That's because it's "*Micro-Windows*" !! All the look
and feel is in one file, windefw.c, the default window proc. I am looking
forward to other look-and-feels. I'll explain a little more how, later.
:
: Are you planning to announce it on Freshmeat now or wait until more it's
: more advanced first (or do you want me to do it for you)?
:
I'd like to announce it as soon as I have a web page/server. Thanks
for thinking about it though.
Greg
