Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- From: "\\o/annabee" <http://www.TheWannabee.org>
- Date: Thu, 31 Mar 2005 04:49:24 +0200
På Thu, 31 Mar 2005 00:03:55 GMT, skrev Beth <BethStone21@xxxxxxxxxxxxxxxxxxxxxxx>:
....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...
Wrong. You have poor observation skills. Because the titlebar is drawn with a gradiant, by the system, and that the captiontext, is replaced by "text..." once the text exceed a certain size, it must be redrawn on sizing.
It's poor sloppy coding...
And its not sloppy making the wrong conclusions, even based on no coding, and wrong observation ?
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? I
No this "logic" only shows you've never done any windows programming at all. Have you done ANY, programming at all? You _cannot_ assume how code works based on theese observations. Its too little info. You seriously need to educate yourself, by actually _code_ something.
t'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?
Its staring everyone but clueless Beth in da face.
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...
Wrong. You have poor observation skills. Because the titlebar is drawn with a gradiant, by the system, and that the captiontext, is replaced by "text..." once the text exceed (shrink) a certain size, it must be redrawn on sizing, the os function, drawing the caption must test for userchanges, and if needed, redraw. I do not favor this way, but what you say is incorrect.
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...
Linux is _slower_ :-))) 3-4 times, on my test machine here....
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"...
I want _less_ work behind the scenes, not more. More control, not less. But I am not saying displaylist are bad. I dont know. But....
Linux is _slower_ :-))) 3-4 times, on my test machine here....
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...
essentially the same prosess, just seem diffrent. The api call also amounts to a list, and can be created like one as well. maybe i adopt the idea as i am now rewriting, using
Diego Fraga's work as a template.
But the advantage will _not_ be the displaylists, but Fraga's fast gdi approach + my own, fully rewritten drawing. and espesially, _clipping_ functions.
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...
Linux is slower.... :-)
Linux is _slower_ :-))) 3-4 times, on my test machine here....Not only on redraw mind you...
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"...
I see _no_ immidiate advantage of some magic keyword _displaylist_. you seem to think that its the displaylists that do the drawing, and more important : clipping :-))
BUT, if anyone out there is developing a GUI OS, t
It woun't be you, you silly cow, thats for sure :)))
Nice...I think not...
Beth :)
-- http://TheWannabee.org .
- Follow-Ups:
- References:
- Prev by Date: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Next by Date: Re: Links to free online media
- Previous by thread: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Next by thread: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Index(es):
Relevant Pages
|
