Re: Linux, X, ld, gcc, linking, shared libraries and stuff

Johannes Kroll wrote:
> Sure. What I also find completely stupid is how the "painting" is done
> in Windows. It detects that an area of a window has to be repainted.
> Then it sends the WM_PAINT msg (and several others, see WinSight or my
> tool) to the app, which then does:
>
> BeginPaint(...) // So NOW we START painting! ;)
> CreateBrush(blah) // create a brush because we need it later...
> FillRect(...) // to fill a rectangular area with GREEN!
> DeleteBrush(..) // We have to clean up of course..
> EndPaint(blah) // DONE painting!
>
> Which is completely redundant. Why can't you just create a
> window/control etc. and define how it looks like, and then the GUI code
> paints it whenever needed? i. e. the rendering method for some text is
> always the same: you call the API that Draws some Text. So why do you
> have to duplicate the above code every time you create some window? Why
> must the app first "erase the background" and then "paint" anything?
> This is really amazingly stupid, and I first couldn't believe it's done
> this way.

Yeah, agreed absolutely 100%; X has the same idiocy in it too...

The "erase the background" is the nuttiest thing...as there's no "double
buffering" then this is a case of "overdraw" (writing to the same pixels
more than once) and generates _FLICKER_...how distinctly amateurish a
method...

And if you have the "show window contents while dragging" switched on
(which you probably do) then grab the bottom-right corner of the window and
drag it around in circles...around and around...but keep your eye on the
titlebar text...

Nice flickering, eh? Ah, what "professionals"!

Even without "double buffering", this problem could be completely
avoided...

Generally, simply do not generate any "overdraw" at all...only write to
each pixel _once_...then it won't flicker...as simple as that...

But, in the case of the titlebar, there's an even stupider point here:

Why the frack is it constantly redrawing the _WHOLE_ titlebar when you're
resizing the window, anyway? We technically _ONLY_ need to draw the parts
that have _CHANGED_ and can leave the rest of it alone...but the flicker
across the titlebar text reveals that, no, it's constantly being "erased"
then "redrawn", "erased" then "redrawn"...even though, we _KNOW_ that this
part of the window is NOT going to change at all by the very nature of what
"resizing" does visually...

It's poor sloppy coding...and then there's the "visual glitch" on the mouse
cursor in older Windows' versions...it appears for one frame at the old
"hot spot" before "jumping" to the new "hot spot" position...causing the
mouse pointer to "glitch" and "jump", as you move it to the window's edge
and it changes pointer shape...TACKY! TACKY! TACKY!

Another interesting one is with the "Start" menu...if you've not used it
for a while and then click on "all programs" and then work your way down
the "submenus" (basically, we need it _OUT_ of the "cache" to see another
piece of "weirdness" in the programming)...because it's out of the cache,
each "submenu" will need to be loaded in...

It'll be a bit slow to appear...but then it's loading it up into the
cache...this isn't my point...what I want to look at is _HOW_ it draws
things...when it's "uncached", it's usually slow enough for you to _SEE_
this really bizarre thing...when you point to a "submenu", then the submenu
appears but, for a few frames, it's _BLANK_...you know, no icons, no
text...just the outline of the submenu...then, a few frames later, the
contents of the menu appears...

So, why? That is, if the contents of the menu are showing up a few frames
"late", then how does Windows know _exactly how big_ to make the outline?
Do you see what I'm saying? To get the _SIZE_ of the submenu right - which
depends on how many entries are in the menu and is made wide enough for the
_longest_ entry (so, it probably "scans" through the entries to determine
which is the longest, to know how wide to make it for all the entries...and
that would require popping each entry into some "GetTextExtents" API call,
as the font is a proportional font and also can be reconfigured by the user
so it must be working this out dynamically) - then Windows _MUST_ have it
already loaded in RAM...do you see what I mean? It's a subtle point...but
just think about how you would program this yourself...and then think: How
could it possibly know what _size_ to draw the outline of the "submenu", if
it hadn't loaded in all the entries, scanned for which is the longest entry
to know what "width" to use and so on? And if it's loaded in all the
entries for that submenu, then why the frack does it not draw them until a
few frames later?

Strange, strange things are going on inside Windows to justify these
various "visual glitches" and it is _FULL_ of them from top to bottom...it
isn't just these stupid "paint messages" but that Windows itself doesn't
seem to be responding to them particularly intelligently either...it's full
of terribly sloppy code...I mean, if it's constantly redrawing the entire
titlebar over and over when it's totally unnecessary to do that, what other
complete wastes of time is doing all over the shop? This is not good...

> The above method should be available for when you really need it, e. g.
> you want to render some advanced 3D stuff to a window. But normally it's
> really stupid to let the app itself do the painting.

Yes; Basically, what's needed is to use a "display list"...it's a very
simple idea...and is, in fact, what most other graphical systems (flash
movies, PHIGS, OpenGL, DirectX, etc., etc.) all use...

When you create a window, it'll have a "display list" attached to
it...then, by calling API functions, the application can add "graphical
primitives" to the "display list"...So, you know, "AddRectangle(hwnd, 50,
50, 25, 25, RGB(0, 255, 0))"...which adds a rectangle at (50, 50) with
width and height of 25 each, in the colour green...and this goes onto the
"display list"...when the window is uncovered and needs repainting, the
graphics subsystem looks through the "display list" and re-renders whatever
needs re-rendering...no need for "paint messages" because the GUI itself
simply uses what's in the "display list" as it's "rendering
instructions"...

This would mean a _PERSISTENT_ display for windows...that is, when you use
'AddText(hwnd, 100, 100, "Hello, World!")' to the display list then the
text will _STAY THERE_ until you delete the "object" from the display
list...no need to constantly call API to re-draw the text...you add it to
the "list" and then it stays there...

Another point is that these objects could be "manipulated" too...you may
add the text object at (100, 100) to begin with...but later, you can use
the "handle to the object" to call "MoveObject(hText, 150, 150)" and then
the text moves to this new position...if you call it, of course, with
changing co-ordinates every frame, then you can "animate" the
graphics...better yet, why should you do that? Another API:
"SlideObject(hText, 150, 150, 5.0)" to say "move it from wherever it
currently is to co-ordinates (150, 150), taking 5 seconds to do so...then
the graphics system itself can calculate the "tweening" (that is, the
in-between frames needed to slide it smoothly from one position to the
next)...

Even better, you could plop a polygon onto the display list and then call
"MorphObject()", supplying a bunch of new co-ordinates for each of the
polygon's points and an amount of time...then the graphics system
automatically "morphs" the shape from what its current shape to the new
shape, working out the "tweening" automatically...

Well, you've seen all the "fancy tricks" that those "Flash movies" on the
web do, yeah? And, basically, this is exactly the kind of scheme that
Macromedia's "Flash" (and "Director", actually) use to do all their vector
graphics tricks...all the bouncing text and spinning shapes...and, heck,
they even do full-length cartoons and things of a good quality in
"flash"...

And it's not just the capabilities and not bothering applications with
"paint messages"...it's also a means for "optimising" it all...you know, if
the graphics subsystem is in charge of the rendering then it can use all
the "accelerations"...only render that which needs rendering...doesn't
bother drawing anything "obscured" by other objects...and that kind of
thing...

To be honest, "display lists" made sense from the beginning, even with
tight RAM considerations and such...but, these days, they totally make
sense...but it's "backwards compatibility", isn't it? They all decided to
use "paint messages" and now they're stuck with it...

Yet, even DirectX and OpenGL themselves use "display lists" for
rendering...basically, they made the wrong design (not just Windows, X and
other GUIs are equally "moronic" in not using "display lists" for their
graphical components: A _STANDARD PRACTICE_ in all graphical systems,
except GUIs, to be noted)...and now that they have, they can't "undo" it
because of "backwards compatibility"...

BUT, if anyone out there is developing a GUI OS, then please don't repeat
this mistake yet again...use "display lists"...oh, and use an API to "mask"
which "events" to send...and use "peer to peer" for the drivers...and,
well, let's stop copying that which we know to be crap...

> And no, the "common controls" like EDIT, BUTTON etc. are not drawn by
> windows, but by a DLL in your process' address space, in your process
> context. So in a way by your app.

Nice...I think not...

Beth :)


.