if there is a demand I'd expect something to come up
Note that Uber/Lyft do something the taxi companies can not. They scale to meet demand. If 1000 drivers are needed between 6pm and 8pm then they'll likely get 1000 drivers. Taxi companies can't do this as they'd lose money on drivers and cars when all of them are not in use.
Electron (and nearly all retained mode GUIs) will execute 10x more code trying not to execute the rendering code. Just skipping all that checking and jumping to the rendering code is arguably a win in many many cases.
To put some empirical data on it, game devs use ImGUIs because they keep up with perf where as that 10x overhead of retained mode guis creating gui objects, deleting gui objects, marshaling data into and out of gui objects, adding and removing event handlers and callbacks, and then trying to write a bunch more code to optimize all of that never leads to a GUI that is performant enough for the GUIs needed for game dev.
I think if you check actual apps, especially phone apps, you'll find it's not so clear which one wins. Phone apps almost always move in relation to the users fingers meaning the screen is being re-rendered. Usually new GUI elements are moving on and off the top/bottom of the screen. The overhead of creating/deleting/managing those objects is arguably greater than just re-rendering. The screen is already going to be re-rendered. At best you're getting a few cached textures from your retained mode gui all at the expensive of managing GUI objects.
For desktop apps it really depends on the app. It's got nothing to do with the complexity of the UI and everything to do with what the app does. A text editor might be a win for a retained mode GUI. Photoshop/Maya it's less clear. For example Unity is ImGUI and has very complex UI. Much of the UI has to respond in realtime to the state of the user's document that is changing constantly.
> Electron (and nearly all retained mode GUIs) will execute 10x more code trying not to execute the rendering code. Just skipping all that checking and jumping to the rendering code is arguably a win in many many cases.
How do you figure? Rendering a single Truetype letter will have dozens of conditional branches, use complex floating point math, and touch tens of kilobytes of cache. And there are many thousands of them in the GUI. Even if you have rendered cache, there is still lots of memory pressure copying data back and forth.
Compared to that, retained mode GUIs should be much more efficient. Even 50 checks are nothing compared to ability to void rendering one line.
Note this is all predicated on screen being mostly unchanging. For example, as I am typing this comment, everything is stationary except for a single line where I am typing.
> The screen is already going to be re-rendered.
This is the key! As you said, if you have to re-render whole screen anyway, then retained mode GUIs will have to maintain draw state and re-render every element every time anyway -- a strictly worse performance.
But most of the regular apps, like editors and chat clients and web browsers, do not re-render whole screen every time. They only do one thing at a time.
For an empirical evidence, look at WinAPI design: this is a retained mode GUI, with lots of effort dedicated to figuring out invalidated rectangles and which controls need to be rendered. This was the only way to make a GUI which is performant enough.
And yet the WinAPI is not actually preformant for types of apps that an ImGUI excels at
There's best case for Retained mode GUIs and best case for ImGUIs. ImGUIs excel when lots is changing. In a scrolling mobile app the entire page is being re-rendered constantly as the user moves the page up and down. GUI widgets get created and deleted, data gets marshalled in and out, various algorithms are applied to try to minimize re-creating stuff, all code that doesn't need to be executed in ImGUI mode code.
There are tons of cases where ImGUIs win in perf. In fact the reason they are so popular with for game dev is exactly because they vastly out perform retained mode guis. There's a reason there are 100s of books and 1000s of blog posts and articles trying to get retained mode guis to run smoothly. They almost always fail without lots and lots of specialized client side code to try to minimize GUI widget object creation/deletion, reuse objects, minimize state changes, etc, all that code disappears in an ImGUI and they run at 60fps where as all the retained mode guis struggle to get even 20fps consistently as they hiccup and sputter.
Phone apps almost always move in relation to the users fingers meaning the screen is being re-rendered.
I'm not really familiar with the mobile platforms, but given their reliance on battery power, I hope(!) that scrolling is done mostly in hardware and actual re-rendering happens only for areas beyond the scrolling boundary. Of course you will need to re-render when the actual content changes, but not with just scrolling.
To put some empirical data on it, game devs use ImGUIs because they keep up with perf where as that 10x overhead of retained mode guis creating gui objects, deleting gui objects, marshaling data into and out of gui objects, adding and removing event handlers and callbacks, and then trying to write a bunch more code to optimize all of that never leads to a GUI that is performant enough for the GUIs needed for game dev.
That sounds more like an implementation/application problem --- overuse of OOP or an application where too much is constantly changing --- rather than an inherent inefficiency of retained mode. The Windows native GUI, since Win16 in Windows 1.0, was basically designed for retained mode. Immediate mode is more common in games because it's more suited to that application.
I think you have it exactly backwards. Most ImGUI use cases are extremely complex UIs and that's where they excel.
One of the most complex apps out there, Unity, is entirely ImGUI based for the app itself and often has 1000s of controls visible. Going though the screenshots of typical ImGUI usage most of them are on the complex side.
I have the same cringe. I think it comes from feeling inserted as a pretense to authority by writing style. Other examples I cringe at: The use of the word "titular", the phrase "abc cum def", ... For whatever reason they sound pretentious like the author is using them to show off, not to actually inform.
Some others are "I've said it once and I'll say it again", "as I said/wrote/posted/blogged before". Those seem to suggest the author is assuming they are famous/popular enough that their previous content has been read. Of course you could look at it as they are just suggesting you go read their previous post but for whatever reason that specific way of saying it comes across less as info and more as "of course you read my previous post".
I'm aware this is a personal opinion with no basis in reality.
Sounds like what you're doing is proving the NYTimes is part of the fake news problem. I wonder given your data above if the NYTimes could be sued for liable for reporting something easily provably false.
The headline is that Tesla posts "big quarterly loss" and the cause of this is "sales lag". And the article provides information to substantiate that, including a link to Tesla's report:
> Deliveries of Model S and Model X declined to 12,100 vehicles in Q1 compared to our two-year run rate of roughly 25,000 units per quarter. This decline was mainly caused by weaker Q1 demand due to seasonality, pull-forward of sales into Q4 2018 in the U.S. due to the first scheduled reduction of the federal EV tax credit in Q1 and discontinuation of our 75 kWh battery pack. We also had a mismatch between orders and deliverable cars. For example, due to adjustments in pricing mid-quarter, the take rate for the performance versions of Model S and Model X increased faster than we were able to supply
I'd argue an ImGUI does't mix anything. It's just a library. If you want MVC it's up to you to implement your MVC and use your ImGUI as a library. Retained mode GUIs don't magically make your code MVC and ImGUIs don't magically make your code not MVC. That's entirely up to you.
Also ImGUIs are not multiple pass. That's in implementation detail. Unity's ImGUI is multi-pass. One of the most popular ImGUIs (Dear ImGUI) is single pass
I think you're mis-understanding why Unity switched. They only switched their in game GUI system. The entire app of Unity itself uses an ImGUI system and it is massively more complex than any Game UI and runs just fine.
The reasons they switched the in game system are many but they have nothing to do with performance.
The old system would stack up draw calls like nobody's bussiness, doubling drawcalls if you used the built in layout tools. OnGUI being called period would be expensive, even when you had properly implemented your rendering logic, so you’d have to disable the entire game object when you didn’t want to draw.
The docs for mobile literally used to say not to use the OnGUI stuff during gameplay.
I don't believe this is a proven. The amount of code being run to cache objects, create and destroy objects, try not to create and destroy objects, marshal data into and out of GUI objects, manage and respond to events, etc. is easily 10x that of an ImGUI, maybe more. Many GUIs now a days are moved almost constantly. Pretty much all phone apps where the user scrolls through a feed of data. A static GUI doesn't need to be re-rendered in an ImGUI, only if something changes. Sure in some ideal test case the Retained mode GUI wins but I suspect it's far less clear what happens in the real world.
What a rude comment. It's not a specialized term. It's a common term. Immediate mode GUI as a concept is well known. Tens of thousands of programmers use Immediate Mode GUIs. There are several well known Immediate Mode GUI libraries used by tens of thousands of projects.
When I don't know a term I google it. I don't assume the entire world revolves around me and that it's the author job to make their article more verbose because everyone reading it might not know every term.
Here's are galleries of some from one of the more popular libraries
I don't think it's rude at all. I did Google "immediate mode GUI" after reading the first paragraph, because I also didn't know what it meant. The first three results were a Wikipedia snippet which didn't help my understanding at all, a Gist that begins with "Before you continue, if you don't know what IMGUI is don't bother reading this", and then third result was this HN comments section.
I would argue that "immediate mode GUI" is an extremely specialised term.
Specialised enough that I didn't come across it during my years of work on Qt. Work that included reading all the manuals, style guides and UI books we could get hold of.
> Specialised enough that I didn't come across it during my years of work on Qt.
Of course you didn't, Qt is retained.
It's a bit like imperative programming vs functional programming. Before functional programming gained any significant traction, imperative programming was just "programming".
Actually immediate mode came first, retained came later for perf reasons (redrawing the entire screen from scratch every frame is slow, even though immediate mode is easier). The original context was however graphics (OpenGL retained vs immediate modes) rather than UI (widget toolkits started out as retained, like OGL retained scene graphs, likewise canvases have always been immediate).
Of course I didn't? I filled a wall with the books I bought and didn't come across the term. What did I do wrong, what books could I have bought but didn't?
How many of those books weren't about the mainstream GUI toolkits (Qt, GTK, MFC, Cocoa, Swing…)? Has even one of those books described something that resemble "let's redraw everything every frame"? If so, how that technique was called?
> what books could I have bought but didn't?
Possibly none at all. Immediate mode anything is mostly a game dev thing, and what happens in game dev tends to stay in game dev. They don't seem to document their practices as much as other fields do.
Hence my suspicion that the authors of your books didn't even know about IMGUI. They just knew about "the" way to do GUI, which happens to involved retained state.
You're letting the tail wag the dog. You're assuming that people know terms that are used in "possibly none [no books] at all", or put differently, that the set of terms used in books for software developers is uncorrelated with the set of terms software developers may be assumed to know.
BTW, the code in Qt that draws rotated/sheared text/pixmaps was influenced in part by a book or chapter by Michael Abrash, as well as by articles in either Graphics Gems or conference papers (memory's fallible I'm afraid).
I did not find it rude and I agree that a short explanation would have been nice. I had heard the terms Immediate Mode GUI and Retained Mode GUI before but I couldn't remember the details. A short reminder would have been nice. Just a sentence.
p.s. I did get a chuckle from your deleted comment that suggested I was living in a cave. After the heat wave we've had here the last couple of days, I wish I were living in a nice cool cave! ;-)
I knew the term and I didn't find the comment particularly rude, even if I don't agree with it fully.
I agree that the docs could have been improved by providing some sort of definition. But I think something as simple as a link to wikipedia could have been enough.
I also agree that the intended target audience will most likely already be aware of immediate vs retained. Adding the aforementioned link would not have hurt said audience anyway.
He wasn't rude, he politely asked people writing articles to try to be more descriptive. However, in my decades in the industry, I've never heard of "Immediate mode GUI" or "retained mode". Not once in 30+ years. I can't be that common.
Note that Uber/Lyft do something the taxi companies can not. They scale to meet demand. If 1000 drivers are needed between 6pm and 8pm then they'll likely get 1000 drivers. Taxi companies can't do this as they'd lose money on drivers and cars when all of them are not in use.