Graphics stack (GUI) improvements

[Jakub Jermář]

The HelenOS native GUI environment should be further improved and extended.

Details

HelenOS features a compositing GUI described in Petr Koupy's master thesis (see below). The GUI is fairly basic and offers vast room for improvements. The goal of this project is to implement a reasonable subset of the following.

• support for direct rendering in graphic driver infrastructure
• more drawing operations in drawing library (lines, curves, polygons, circles, etc.)
• retained scene description in drawing library
• hardware acceleration of drawing library
• better quality of drawing library output (advanced filtering, antialiasing)
• better precision of drawing library output (floating point coordinates and pixels)
• support for more image and font formats in drawing library
• more widgets in widget toolkit (menu bars, scrolls bars, edit boxes, list boxes, etc.)
• support to minimize and maximize windows
• desktop environment (task bar, icons)
• improvements of terminal emulator (resizing, scrolling, history)
• console applications awareness of resizing and termination of their terminal emulator

What Gains and Benefits will this bring?

HelenOS will become more usable and more user-friendly and visually appealing.

Difficulty

medium

Required skills

A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with a graphics stack implementation would be beneficial.

Documentation

• ​Graphics Stack for HelenOS
• GUI's Users Guide

Possible mentors

HelenOS Core Team, Martin Decky

[Jiri Svoboda]

This ticket calls for incremental improvements, but the GUI needs more fundamental changes. Here are my high-level goals:

• An abstract rendering API and window update protocol that can be used both for App ↔ Display server and Display Server ↔ Display Driver communication and other things
• This makes the communication protocol more independent of the applications.
• Make it possible to conserve memory (compared to all windows being always fully memory-backed)
• Make the memory retention and communication mode a decision of the display server, not an inherent property of the display protocol / API
• Display protocol should explicitly denote frame boundaries and frame timing
• Support a wider range of pixel formats (<32 bpp, >32bpp) including text
• Sound follows picture

[Jiří Zárevúcky]

The GUI should also correctly handle various #pixels-per-line/character settings (not the same as "DPI", which were probably invented by people who never noticed that not all screens are the same size).
Also, input devices should be associated with display/output, same as sound.

[Jiri Svoboda]

This ticket is now replaced by #816 which I am working on.