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

On Thu, 31 Mar 2005 00:03:55 GMT
"Beth" <BethStone21@xxxxxxxxxxxxxxxxxxxxxxx> 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.


> 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. :)


> > 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?

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


> 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. :-)


> 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 :)
>
>
.