OSDev.org

klange wrote:It's probably about time I post in this thread... I worked on Compiz many years ago, spent some time at Apple working on the window server in OS X, and have written two different compositing window managers of my own. Hopefully this isn't too much a rambling mess.
I'll spare you the usual history-of-window-drawing explanation and jump straight to "how we do it now".....

Thanks willedwards and klange! I really appreciate your explanation about your experience with writing compositor! I was actually inspired to start writing hobby os half a year ago, after seeing toaruos and convinced that it's possible to write a such a great os by oneself.

I am now trying to implement move window in my compositor, the way my method works is:
After user moves a window, for example, 1 pixels to the right, and 2 pixels to the top, this would create three rectangle regions that need to be redrawn.
Then, for each of rectangle A and B, find all windows within the rectangle and draw them from back to front. Then simply draw the moved window on rectangle C.



This is still running a bit slow in QEMU, i m interested how you would implement this ?
Thanks!

Hi,

szhou42 wrote:This is still running a bit slow in QEMU, i m interested how you would implement this ?

I'd implement a 3D renderer capable of doing hundreds of textured polygons at "good enough for software rendering" frame rates. After that is done, tested and working; then I'd decide that "tens of textured rectangles that happen to be parallel with the screen" is trivial for the existing 3D renderer to handle.

Of course then I'd decide that "rectangles that happen to be parallel with the screen"" is boring and that the 3D renderer is capable of doing far more interesting GUIs.


Cheers,

Brendan

Brendan wrote:Of course then I'd decide that "rectangles that happen to be parallel with the screen"" is boring and that the 3D renderer is capable of doing far more interesting GUIs.

Even after 20 years, Microsoft Bob is still the most efficient way for power users to use their computers.

Brendan wrote:I'd implement a 3D renderer capable of doing hundreds of textured polygons at "good enough for software rendering" frame rates. After that is done, tested and working; then I'd decide that "tens of textured rectangles that happen to be parallel with the screen" is trivial for the existing 3D renderer to handle.

Of course then I'd decide that "rectangles that happen to be parallel with the screen"" is boring and that the 3D renderer is capable of doing far more interesting GUIs.

I reached exactly this conclusion today morning and now I'm testing and writing an interface for appropriate drivers.

Is it possible to develop GUI based on OpenGl ? What are the prerequisites ?

Hi,
Some GUIs already exist over opengl.
I know of :
- GWEN
- CEGUI
- SFML ( over SDL )

Google for it and pick the one you like the best, or the one that will be easy to port.

another opengl gui in one header.... nuklear

https://github.com/vurtun/nuklear

Hi,

For anyone interested, I slapped together a basic introduction to (software) 3D rendering.


Cheers,

Brendan

Magnificent !

I just found out the reason why my GUI is so slow.... I was developing the os in a ubuntu machine, which is inside OSX(i m using a macbook air).
And the os runs in qemu, which adds another layer of virtualization.

After booting my os in a real machine with kvm enabled, my GUI is literally flying

Brendan wrote:For anyone interested, I slapped together a basic introduction to (software) 3D rendering.

Hi Brendan.

I haven't done graphics in a while, but

The left plane can be described by "x = 0" (and if all of a polygon's z coordinates are negative then the polygon must be outside the viewing volume and the polygon can be culled). The right plane can be described by "x = horizontal_resolution". The top plane can be described by "y = 0". The bottom plane can be described by "y = vertical_resolution"

Shouldn't these limits be x=-horizontal_resolution/2 to x=horizontal_resolution/2 and ditto for y - from y=-vertical_resolution/2 to y=vertical_resolution/2 (or am i missing some step there?)

dozniak wrote:Shouldn't these limits be x=-horizontal_resolution/2 to x=horizontal_resolution/2 and ditto for y - from y=-vertical_resolution/2 to y=vertical_resolution/2 (or am i missing some step there?)

It depends. Most UI/2D applications use 0,0 to denote a corner of a window rather than the center. This might be a assumption Brendan made? (Haven't read his article yet.)

- Monk

EDIT: Reading his wiki page now, in section 3 Brendan says:

Brendan wrote:The first step is building a transformation matrix to convert coordinates in the camera's coordinate system into screen coordinates. This is special and unlike the other steps. For this you need a projection matrix (which essentially does "x = x/z; y = y/z"), a scaling matrix (to scale coordinates to suit the screen's resolution, possibly derived from the camera's field of view), and a translation matrix (which subtracts half the screen's horizontal resolution from x values and subtracts half the screen's vertical resolution from y values). These 3 matrices should be combined (multiplied) to form the final "camera to screen transformation matrix".

That answers you question better I think.

I guess I mixed up screen coordinates with camera coordinates.

dozniak wrote:I guess I mixed up screen coordinates with camera coordinates.

been there... done that.... I did it on a medical application viewing a CNC milling a prosthetic... took two days to find. I feel your pain

szhou42 wrote:I just found out the reason why my GUI is so slow.... I was developing the os in a ubuntu machine, which is inside OSX(i m using a macbook air).
And the os runs in qemu, which adds another layer of virtualization.

After booting my os in a real machine with kvm enabled, my GUI is literally flying

(・ω・`)

At least now drawing performance will be the least of your worries.