OSDev.org

omarrx024 wrote:I have alpha blending, double buffering, rectangles (solid and transparent), lines (solid and transparent), mouse cursor support, BMP image rendering, and many other things in both 32-bit and 24-bit graphics modes, transparently to the user.

omarrx024 wrote:I'm the exact opposite. I usually get bored with UI development, and focus more on core things.

zlixine wrote:

omarrx024 wrote:I'm the exact opposite. I usually get bored with UI development, and focus more on core things.

totally disagree the Ui always is the top of OS developing.

MollenOS wrote: I'm building my GUI in OpenGL, but I've spent the last few months improving stability and robustness of the core itself. So I guess I would agree a strong core comes before GUI.

Target Applications
...
Scalable User Interfaces
    OpenVG may be used to render scalable user interfaces, particularly for applications
    that wish to present users with a unique look and feel that is consistent across different screen resolutions.

Low-Level Graphics Device Interface
    OpenVG may be used as a low-level graphics device interface. Other graphical toolkits,
    such as windowing systems, may be implemented above OpenVG.

zaval wrote:

MollenOS wrote: I'm building my GUI in OpenGL, but I've spent the last few months improving stability and robustness of the core itself. So I guess I would agree a strong core comes before GUI.

I'm a total noobass in graphics so I'm not ashamed to ask. Is that OpenGL suitable for GUI at all? Isn't it a 3D API? Even if it's a matter of subsetting (2D is a subset of 3D), it's going to be a huge overkill - to implement that monstrous API (that is getting outdated yet!), intended for drawing complex 3D objects (games, CAD etc) just for using its small subset of functions/objects/concepts. GUI is hell of complexity, but it's not 3D at all! And there is yet a question - will it be so efficient made this way? The very same standardization body, produced loads of other specifications, that tell about themselves as a 2D stuff, specifically targetting this area, GUI. Like what that OpenVG is for? EGL? Aren't these more suitable for GUI. Here, from this page they talk about it as exactly the thing for GUI:

Code: Select all

Target Applications
...
Scalable User Interfaces
    OpenVG may be used to render scalable user interfaces, particularly for applications
    that wish to present users with a unique look and feel that is consistent across different screen resolutions.

Low-Level Graphics Device Interface
    OpenVG may be used as a low-level graphics device interface. Other graphical toolkits,
    such as windowing systems, may be implemented above OpenVG.

Kinda this thing, eh? What one can do with OpenGL for Windowing?

MollenOS wrote:And yes, I agree that performance is a consideration, and one I'm still trying to figure out might be a problem with a software renderer. Currently I'm using llvmpipe as my software renderer and it gives me enough performance for now, but I am considering switching to OpenSWR as the backend renderer instead of llvmpipe as that should be faster.

zaval wrote:OpenVG is supported by the current GPUs on ARM SoCs, especially those found in significantly cheaper than their smartphone counterparts SBCs, whereas support of Vulkan is a looong way to go. Even OpenGL ES support is lagging behind*, especially for linux. I didn't know OpenVG was obsoleted, since Khronos still advertizes it.
I didn't mean ignoring OpenGL, I questioned its relevance to the GUI implementation. Basically I just don't understand how it's supposed to be used for this task.

* - For example, a so frequently found in SBCs Mali 400:
Vulkan - NO
OpenGL ES - 2.0
OpenVG - 1.1
The same goes to Mali 450.

Pricier and newer things like RockPro64 or Odroid-N2 (Mali T860 and Mali G52 resp.):
Vulkan - 1.0 (T860), 1.1 (G52)
OpenGL ES - 3.2
OpenVG - 1.1

But for example those opensource dudes (and ladies), that try to bring opensauce ARM GPU support for linux, are struggling with delivering OpenGL ES 2.0 only for now (panfrost project). So Vulkan is unavailable even if it is there, even OpenGL ES 3.x isn't.

Korona wrote:

MollenOS wrote:And yes, I agree that performance is a consideration, and one I'm still trying to figure out might be a problem with a software renderer. Currently I'm using llvmpipe as my software renderer and it gives me enough performance for now, but I am considering switching to OpenSWR as the backend renderer instead of llvmpipe as that should be faster.

Interesting. I'm currently using softpipe; I plan to switch to llvmpipe but so far, I didn't have to time to finish my llvm port. Were there any obstacles with getting llvmpipe to work on your OS, or does it simply work once llvm works?