Readit News logoReadit News
tokyodude commented on Can Uber ever make money?   economist.com/business/20... · Posted by u/lxm
cc439 · 6 years ago
How much of that benefit is purely short-term though? In a hypothetical world where Uber and Lyft's current pathway to profitability never pans out, what are the ramifications. The most obvious one is that their fares will increase by 25-50% depending on the market, pricing them well above the legacy taxi services that existed before the arrival of these VC-backed companies. The second most obvious ramification is that many of those legacy taxi services have been run entirely out of business in smaller markets. My home county of 1m+ people is now down to 1 shady taxi service with a handful of ancient, beat up Crown Vics (last produced in 2011) and they only hang on due to the incredibly low standards for taxi regulation in our region. If Uber and Lyft fail or become far less useful due to cost increases, there are significant barriers to entry for a new, clean, and professional taxi service to enter the market as they don't get to play by VC rules and have to start a highly capital intensive (for a small business) operation by conventional rules while only being able to attract a customer base entirely through conventional means of marketing, and all at a very small cost advantage versus the ride sharing giants.
tokyodude · 6 years ago
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.

tokyodude commented on Immediate Mode GUI   behindthepixels.io/IMGUI/... · Posted by u/sytelus
theamk · 6 years ago
> 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.

tokyodude · 6 years ago
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.

tokyodude commented on Tesla Posts Big Quarterly Loss as Its Electric-Car Sales Lag   nytimes.com/2019/04/24/bu... · Posted by u/pseudolus
danso · 6 years ago
The quarterly loss comes directly from Tesla’s own reporting. You don’t think loss is derived only from revenue, do you?
tokyodude · 6 years ago
The title of the article is that sales are lagging but sales are provably not lagging
tokyodude commented on Immediate Mode GUI   behindthepixels.io/IMGUI/... · Posted by u/sytelus
theamk · 6 years ago
I disagree. With all downsides of electron, it does not generally re-layout and re-render entire screen on any mouse move. IMGUI does.

So while Electron will lose in memory/disk used, IMGUI will lose in CPU usage (battery life) once the software is complex enough.

tokyodude · 6 years ago
I disagree with your disagreement :)

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.

tokyodude commented on Immediate Mode GUI   behindthepixels.io/IMGUI/... · Posted by u/sytelus
mmozeiko · 6 years ago
Here's an browser demo for dear imgui (https://github.com/ocornut/imgui) library:

https://pbrfrat.com/post/imgui_in_browser.html

For modal demo check "Popups & modal windows" -> "Modals" example.

This is how it looks in C++ code: https://github.com/ocornut/imgui/blob/master/imgui_demo.cpp#...

tokyodude · 6 years ago
Here's another

https://greggman.github.io/doodles/glfw-imgui/out/glfw-imgui...

In the "ImGUI Demo" window start expanding the collapsed items or from the menus pick "Examples"

Note that no effort has been spent to actually make the demo web browser friendly so there are rough edges.

tokyodude commented on Immediate Mode GUI   behindthepixels.io/IMGUI/... · Posted by u/sytelus
avodonosov · 6 years ago
Again IMGUI. Several years ago there was a chain of videos and blog posts by different authors. People were drawing two buttons and saying "see how easy it is".

In this post the author seems to go further than two buttons, but I'm skeptical. I wish there was a video showing how it works in dynamics - inputs clicked, texts entered, scrollbars scrolled, dialogs dragged around. Or source code available to build and try locally.

From the code in the post I suppose the majority of UI is dead - can not be interacted with.

I think IMGUI can only be convenient for very simple cases.

In real frameworks the lowest level is immediate mode (see WM_PAINT in WinAPI), but real UI needs quickly evolve them into the traditional RMGUI.

BTW, this thinking is my source of doubts about React.

tokyodude · 6 years ago
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.

https://cloud.githubusercontent.com/assets/8225057/20628927/...

https://raw.githubusercontent.com/wiki/ocornut/imgui/web/v16...

https://user-images.githubusercontent.com/16171743/50757906-...

https://user-images.githubusercontent.com/8225057/51042368-6...

https://user-images.githubusercontent.com/870320/51073482-ba...

See https://github.com/ocornut/imgui#Gallery for more

tokyodude commented on Bad Habits Creeping into Your Writing?   lithub.com/are-these-bad-... · Posted by u/blegh
coat · 6 years ago
There should be a version of this for hacker news comments and tech blog posts. Every time I see the phrase 'that said' or 'that being said' I involuntarily cringe.

https://hn.algolia.com/?sort=byDate&prefix&page=0&dateRange=...

tokyodude · 6 years ago
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.

tokyodude commented on Tesla Posts Big Quarterly Loss as Its Electric-Car Sales Lag   nytimes.com/2019/04/24/bu... · Posted by u/pseudolus
radium3d · 6 years ago
Seasonal 4th to 1st quarter may have been a loss but these numbers stand out to me as being a bit more important.

Cars sold:

Q1 2019: 63,000

Q1 2018: 29,980

Q1 2017: 25,000

Q1 2016: 14,820

Q1 2015: 10,045

Q1 2014: 6,457

Q1 2013: 4,900

Q1 2012: 0

Revenue

Q1 2019: $4.5 billion

Q1 2018: $3.4 billion

Q1 2017: $2.7 billion

Q1 2016: $1.6 billion

Q1 2015: $1.1 billion

Q1 2014: $713 million

Q1 2013: $562 million

Q1 2012: $30 million

Q1 2011: $49 million

Q1 2010: $21 million

tokyodude · 6 years ago
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.
tokyodude commented on Immediate Mode GUI   behindthepixels.io/IMGUI/... · Posted by u/sytelus
bdowling · 6 years ago
Immediate mode GUIs are an extension of the simple display update loop: (1) update display, (2) check input, (3) goto (1). Immediate mode GUIs add a context parameter to the update function. In the draw context, the update function draws to the screen. In the input context, the update function doesn't draw; instead it checks if mouse clicks or keystrokes should do something.

For example, part of the update function might look like this:

    if (Button("Do That Thing")) 
        doThatThing();
In the draw context, the call to Button will draw a button on the screen and return False. In the input context, the call to Button will check if a mouse click fell within the area it would have drawn. If so, it will return True and the callback will run.

An immediate mode GUI is basically the opposite of a typical Model-View-Controller GUI because it deliberately mixes the Model, View, and Controller together into one function. Just one function draws the GUI based on whatever state it's in and whatever the model is. The same function gets reused in a different context to update the GUI state or handle callbacks.

tokyodude · 6 years ago
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

https://github.com/ocornut/imgui

tokyodude commented on Immediate Mode GUI   behindthepixels.io/IMGUI/... · Posted by u/sytelus
BoorishBears · 6 years ago
I find it ironic that Unity is used as an example... the immediate mode UI was/is considered a joke.

Terrible performance, doesn’t scale to UIs more complex than a form (... like the ones many games tend to have)

It got to the point where there was a website dedicated to track when we’d get the current non-immediate UI, and Unity actually hired the developer of the leading non-immediate mode UI library in the asset store to work on their own offering.

tokyodude · 6 years ago
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.

u/tokyodude

KarmaCake day2119April 13, 2018View Original