Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libui: GUI library in C

github.com

Post reply on HN
Print view View original

161–170 of 186 posts

Re: Libui: GUI library in C

#161

Post by audidude »

stuaxo wrote: post #142
audidude wrote: post #103

Earlier quoted context omitted.

> It's also getting slower at each release, it keeps breaking visual consistency and basic features get removed or heavily deprecated in favor of a "dumbed down" approach. This is simply not true. We are closer to hitting 60 fps (or whatever your EDID actually presents) than ever before, and staying locked to that. The more complex of an interface you create, the harder that is, but that is no different today than ev…

There is some great info in this post. The draining of the swamp is really good work, and seems to be starting to pay off. I hope for the CSS theme changes there is some sort of migration, or warning - was trying gnome-staging on Ubuntu and lots of things broke with the change. Fingers crossed that GL will bring GL Enabled cairo at the same time.

Drawing with cairo-gl/glitz/etc was never really faster than drawing on the CPU. I think it's more likely that we'd use the image surface (backed by pixman) and texture uploads.

If we are hitting a path where we expose the immediate mode style drawing (a'la cairo) then we've probably already lost the performance race.

Re: Libui: GUI library in C

#162

Post by wander_homer »

skrebbel wrote: post #156
pcwalton wrote: post #147

Earlier quoted context omitted.

I actually think that CSS is better for drawing with modern GPUs than native UI frameworks are. CSS is declarative, which enables global optimizations--very important on GPUs, where state changes are expensive and overdraw hurts. By contrast, native UI frameworks were designed for slow CPU rendering in the '90s via legacy APIs like GDI.

I believe you, but still my layman's observation is that the average cocoa/win32 ui feels much snappier than the average web app. I have no proof but I'm pretty sure most people here would back me up. If it should be faster with CSS, why isn't it? In fact, I develop a web app. What am I doing wrong?

Maybe because the GPUs aren't used efficiently with the current technology. E.g. Webrenderer for Servo was designed to make great use of GPUs right from the beginning and the first results are really impressive.

Re: Libui: GUI library in C

#163

Post by pcwalton »

skrebbel wrote: post #156
pcwalton wrote: post #147

Earlier quoted context omitted.

I actually think that CSS is better for drawing with modern GPUs than native UI frameworks are. CSS is declarative, which enables global optimizations--very important on GPUs, where state changes are expensive and overdraw hurts. By contrast, native UI frameworks were designed for slow CPU rendering in the '90s via legacy APIs like GDI.

I believe you, but still my layman's observation is that the average cocoa/win32 ui feels much snappier than the average web app. I have no proof but I'm pretty sure most people here would back me up. If it should be faster with CSS, why isn't it? In fact, I develop a web app. What am I doing wrong?

Because browsers are not currently architected to make good use of modern hardware.

Re: Libui: GUI library in C

#164

Post by imtringued »

pcwalton wrote: post #145
Razengan wrote: post #66

Earlier quoted context omitted.

> I was recently thinking that operating systems should ditch their custom desktops in favor of a browser based UI. Here's the really funny thing though, if you just think about it for a second: Whether browsers become as powerful as operating systems, or operating systems become as convenient (for users and developers) as browsers, The end result will be exactly the same. Yep. Consider how we use browsers vs. native…

> Now obviously what browsers are missing is the UI responsiveness, efficient hardware performance, and OS integration. > It will take far less work to make the discoverability and acquisition of native apps as convenient as typing in a web address. I don't see that as the case at all. The UI libraries are just the tip of the iceberg. In fact, I think CSS is better suited to hardware acceleration with modern GPUs tha…

As a counterpoint these "imperative systems" don't need hardware acceleration to be responsive. (why the hell does responsive mean "looks good on my phone" nowadays?)

Re: Libui: GUI library in C

#165

Post by pcwalton »

imtringued wrote: post #164
pcwalton wrote: post #145

Earlier quoted context omitted.

> Now obviously what browsers are missing is the UI responsiveness, efficient hardware performance, and OS integration. > It will take far less work to make the discoverability and acquisition of native apps as convenient as typing in a web address. I don't see that as the case at all. The UI libraries are just the tip of the iceberg. In fact, I think CSS is better suited to hardware acceleration with modern GPUs tha…

As a counterpoint these "imperative systems" don't need hardware acceleration to be responsive. (why the hell does responsive mean "looks good on my phone" nowadays?)

Drawing everything on CPU and overdrawing/changing state like crazy (in kernel mode, even, for GDI!) is very much not responsive and not efficient. It only seems that way because (1) graphically, those apps are so simple, as the systems were designed for '90s hardware; (2) desktop CPUs are so fast that you can be really slow and still remain responsive.

Re: Libui: GUI library in C

#166

Post by microcolonel »

random443 wrote: post #95
distances wrote: post #73

Earlier quoted context omitted.

> [...] GTK is perfectly fine for Linux. This is great news, so now it is the best time to make thin wrappers around these stable things so that we can all go make useful software.. Hoping not to start any kind of framework quarrel, but my understanding was that quite many applications (such as Wireshark, Subsurface, and OpenShot) are moving from GTK to Qt very much due to Qt being more stable. Or is the main reason…

My personal reason is that GTK 3+ lost his track in what constitutes a desktop widget set. It's also getting slower at each release, it keeps breaking visual consistency and basic features get removed or heavily deprecated in favor of a "dumbed down" approach. So if the non-technical users are actually migrating to dumb web-apps and couldn't care less, the technical crowd which demand power features and efficiency ar…

I'd like you to substantiate the claim that it "gets slower at each release" before I'll accept it, it conflicts with my experience. I've seen every single GNOME application get consistently faster for the last five releases; today (with GNOME 3.20) they render at ludicrous speed on even my oldest intel boxes.

Re: Libui: GUI library in C

#167

Post by c-smile »

I was considering that approach (using native OS widgets) on initial stages of my Sciter (http://sciter.com) development.

It didn't went through for the simple reason: set of common widgets in GUI OSes is quite small: buttons, editboxes, selects and that is it. What about menus, toolbars, treeviews/virtual lists, etc. etc. ?

So yes, you can do with that common set something extremely simple like alert() or prompt() in browsers. But nothing close to full scale applications.

Yet graphic primitives... GDI on Windows does not know anything about alpha channel or anti-aliasing... But CoreGraphics does. What would be the common set in this case?

Again, idea of reusing OS widgets and native platform's look and feel in multiplatform GUI toolkits is a perpetual dream of programmers since initial version of Bible was written. wxWidgets or SWT are such examples.

But event they failed to achieve one of their primary goal - native platform's look and feel. Does anyone know any wxWidget or SWT application that look native on, say, OSX ?

So if you are designing application of "one red button 'Start'" then this approach will work of course. But even in that case ... how to create really red button in OSX? Or on Windows? You will want something custom drawn... but you haven't common graphic primitives and so on.

Re: Libui: GUI library in C

#168

Post by c-smile »

infogulch wrote: post #151

Working with Atom has opened my eyes to the idea that the web technologies are the ultimate UI platform. HTML+CSS can build any user interface and allow extreme customization. Atom is slow and chromium a resource hog, but these are limitations of the current implementations, not inherent to the technologies themselves. A Servo-based UI toolkit with well thought out DOM bindings could solve both of these problems spec…

"Atom is slow and chromium a resource hog..." Check Sciter (http://sciter.com) then. It is single dll/so/dylib of 4-8mb without any external dependencies.

Re: Libui: GUI library in C

#169

Post by infogulch »

c-smile wrote: post #168
infogulch wrote: post #151

Working with Atom has opened my eyes to the idea that the web technologies are the ultimate UI platform. HTML+CSS can build any user interface and allow extreme customization. Atom is slow and chromium a resource hog, but these are limitations of the current implementations, not inherent to the technologies themselves. A Servo-based UI toolkit with well thought out DOM bindings could solve both of these problems spec…

"Atom is slow and chromium a resource hog..." Check Sciter ( http://sciter.com ) then. It is single dll/so/dylib of 4-8mb without any external dependencies.

Licensing & Prices > Indie+ (Windows, OS X, Linux versions) > $1260 + yearly upgrade fee

> We have no intention to cover full CSS1/CSS2 attibute map.

Yeah that's not gonna work out for many projects.

Re: Libui: GUI library in C

#170

Post by jventura »

jventura wrote: post #97
jventura wrote: post #59

This is a very good approach for the current times! As far as I understand from the source code, libui is a thin C wrapper that makes calls to each platform native ui framework. For instance, to create a window on OSX it calls the corresponding Cocoa function, for Linux the corresponding GTK function, etc. So, unlike Qt and GTK which are heavy cross-platform libraries because they can "draw" their own widgets themsel…

Had some troubles compiling on OSX Mavericks, but now that I've just tested it, it sure looks 100% native to me and perfectly integrates with the platform (file dialogs, osx font dialog, etc.) and much much better and lighter than Qt and other cross-platform tools I've been using so far. I'm definitely going to try to implement a python wrapper around this as it seems usable enough as it is now.. :)

Started pylibui at https://github.com/joaoventura/pylibui. Pretty barebones for now, but hey, it shows a window!
Post reply on HN