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

Johannes Kroll wrote:
> Beth wrote:
> > 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...
>
> IMHO the best possibility would be to use one "extra buffer" the size of
> the screen, where everything is drawn on, and then updated. So you can
> do overdrawing if you must. That's probably the best compromise between
> simplicity, "flicker-free-ness", memory use, and speed.

Yes; "Double buffering"...

When using DirectX in "full screen mode", then this is, in fact, exactly
what happens...

Simply, they can't use "double buffering" in the windowed mode because,
originally, video cards / system RAM could NOT afford to have a second
screen (too much RAM)...and, once that decision has been taken, then they
have to maintain it for "backwards compatibility"...

Also, "double buffering" in games often uses a "flip" method for fast
animation (the "back buffer" and "front buffer" are simply "swapped")...the
problem is that, in windowed mode, you'd then either have to ask all the
windows to "repaint", in order to re-build all the windows in the new
buffer..._OR_, alternatively, when the screen if "flipped", the "front
buffer" has to be _COPIED_ to the "back buffer"...

It's possible...but it was asking too much originally for the earlier
Windows to use up twice as much RAM for a "back buffer" and then constantly
"flip and copy", "flip and copy" (before AGP buses and such, being able to
maintain the "data rate" for doing that at a reasonable frame rate for a
high resolution screen, again, was asking too much)...

Today, of course, games and such do exactly this kind of thing all the time
with "double buffering"...but this was just "infeasible" way back when
Windows / X were first around...

And it's "backwards compatibility": Once they chose this scheme, then it's
been retained to keep the "compatibility"...note, though, that Direct3D /
OpenGL - added later when "double-buffering" and such is now completely
feasible - _DO_ use "display lists" and _DO_ use "double buffering" and all
that stuff...

It's perfectly understandable, as I say, why things ended up as they
did...this was what seemed right at that time...now, though, the situation
is different and a new scheme might be better...Windows and X, though, will
stay the way they are, most likely, because of "backwards compatibility"...

This was why I was saying "if someone's writing a new GUI OS" at the
end...you know, the older stuff can't do it like this because of
"legacy"...but a brand new GUI OS can now "re-evaluate" that using "display
lists" and "double buffering" and other such things _from the beginning_ is
a good idea...

If you were starting from scratch _NOW_ then you wouldn't do it that
way...and that's basically what I'm talking about...what "way" would be
most appropriate and useful _TODAY_...

> > 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...
>
> And as you mentioned, there's more stuff like that, because it's all a
> big hack. :)

I suppose Microsoft _DO_ deserve credit that it's the most gigantic
"hack"...you know, hats off for how they can "hack" at something so big for
so long and it still (barely) holds together...that part is "impressive",
so to speak...how you could "ad hoc" and "hack" out something like
this...well, you know what they've been doing for 20 years...

It's "impressive hacking" but that doesn't mean "hacking" out such
solutions is really the best way to go about it...they are building a
"house of cards" and it's not surprising, then, that, from time to time, we
find the "house of cards" _falling down_...

> > > 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"...
>
> Exactly, that's what I mean. Except I wouldn't call it display lists,
> but "you create the thing, and then it's there until you destroy it."
> :-) What would be more natural?

Ah, "Display list" is just the "jargon"...this is what it's called in all
the systems that use such a thing...I just thought I'd use the "correct
term" so that others would know what I'm talking about...

But, yes, essentially, what we're really talking about - if you'll pardon
yet more of "the jargon" - is "persistence"...which just means, as you say,
"once you stick it there, it stays there until you destroy it"...the
objects "persist"...hence, it is a "persistent display scheme"...

The point is that - as the "jargon" demonstrates - this is NOT any kind of
"news" in graphics systems in general...they basically _ALL_ use "display
lists" these days...from Direct3D to OpenGL to PHIGS to Flash movies to
whatever...

If you like, in the "specialist" field of "graphics", this is a
well-established "Good Idea"...they _ALL_ use them...there are other
"tricks" like the use of "hierarchies" of objects...adding in that third
dimension...and so forth...

But remember that these GUIs were designed in the early '80s...copying
stuff from Xerox in the '70s...at this point in time, it was NOT
"well-established"...also, simply, hardware just wasn't as good...you
couldn't just easily "reserve a back buffer"...that would have taken too
much RAM...you couldn't expect 60 / 70 / 100 frames per second rendering
either...it was done by the CPU then and it had to pass over ordinary
"buses", not specially designed "AGP" or "PCI express x16" buses, expressly
designed to be faster and higher bandwidth to handle the very high demands
of graphics at such rates in high resolution...

So, you know, simply, "display lists" became "well-established" _AFTERWARD_
(the idea was known in the '80s but not "well-established" or that everyone
necessarily knew about them)...and what's "normal" today would have been
demanding far too much - if not outrightly infeasible and impossible - for
hardware of that time...certainly, it would have _COST MORE_, as
"economics" comes into things too, of course...

Problem is, we now have the "legacy" of this...the "backwards
compatibility" thing...I'm sure if Microsoft or those designing a new X
were to "start from scratch", then they'd possibly choose a very different
design...make use of "display lists" in the GUI itself...as noted, the
later stuff - DirectX, OpenGL, etc. - _DO_ use "display lists" and "double
buffering" and whatever they can get their hands on...

> Another advantage of this method is, if you optimize the drawing code in
> the GUI system, all apps benefit.

Yeah, that's a big benefit...and is one that _IS_ used by these graphical
systems that have "display lists", usually...

> > 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"...
>
> I've used Flash myself a bit. Using the "tweening" stuff in a GUI is
> really a nice idea... And I reserve the right to maybe, possibly, use it
> at some time in the future, if you don't mind. :-)

Of course not; If I wanted to keep it "secret" then I wouldn't go
"blabbing" it around here, would I? I've always said that any ideas I state
on the newsgroup, I consider "public domain"...the "reward" for me would be
seeing GUIs and such that work this way (or tools that are "incremental" or
whatever :) because I do believe it's much better - which is why I talk
about these things and explain that - so I'd benefit using your "future
GUI-to-be" when you may get around to releasing it...I don't even care
about "credit"...pretend it's your own idea, if you like...you know, I
consider the _idea_ its own reward...if it were to lead to lots of great
GUIs with super programming tools and so forth then that is my reward:
Finally, "freedom" from all the crap that annoys me so much today ;)...

Yeah, if you've used Flash then you exactly know what I mean...because this
would be kind of using something Flash-like as the GUI's graphical
subsystem...and, yeah, you've got it: The "tweening" possibility would
really make a large "jump" in GUI appearances...with icons "opening up"
into windows and menus animating smoothly...clicking a button and then it
"moves up" to become the "title" for the window...

Basically, you know how on Hollywood movies, they show people "using
computers" (always Apple Macs...they just look "too cool" for Hollywood to
use anything else on screen...well, you need "beautiful computers" for the
"beautiful people" to be using, right? ;)...and the GUIs shown on the
screen always look ultra cool...they aren't any real GUI out there...but
their "effects department" comes up with some graphics to "fake up" their
own desktop...and they tend to have all these "effects"...spinning windows,
animating icons, etc....well, why the crap can't we actually have GUIs that
look just that "ultra cool"? ;)...

Beth :)


.