[HN Gopher] Unanswered user makes question their MS thesis and a...
___________________________________________________________________
Unanswered user makes question their MS thesis and answers self 2
years later
Author : anderspitman
Score : 175 points
Date : 2021-01-03 18:57 UTC (4 hours ago)
(HTM) web link (stackoverflow.com)
(TXT) w3m dump (stackoverflow.com)
| Hnrobert42 wrote:
| That's pretty awesome.
|
| Admittedly, all I know about immediate mode and retained modes
| GUIs, I learned from this post, but I wonder why there's no
| library that uses both. Could a library: 1. Use immediate mode to
| calculate the display. 2. Use retained mode as long as the amount
| of change is below a certain threshold. 3. Switch to immediate
| mode above the threshold. And so on.
| megameter wrote:
| They meet in the middle when we talk about layout computation.
| Layout often flips between needing a globally-optimized
| solution of some kind(how to pack many boxes given some
| parameters of box size), and needing a fast, simple dynamic
| adjustment(same drawing algorithm with different numbers passed
| in). And what happens is that when the layout gets complex, the
| simple dynamic adjustment impacts the overall solution. Parts
| of the layout may also contain their own state, like window
| positioning. So even in immediate GUI there is retained
| elements, and vice versa.
|
| It's a complex tangle, all in all.
| anderspitman wrote:
| In practice they do tend to be mixed, if not in exactly the way
| you describe. Immediate mode systems often retain/cache a lot
| of state under the hood for performance reasons, and determine
| exactly what needs to be redrawn on each iteration. Virtual
| doms (React, Vue, etc) are a great example of this.
| c-smile wrote:
| > but I wonder why there's no library that uses both
|
| Sciter (https://sciter.com) uses both, as internally as on
| user's level.
|
| For example you may want to define this: var
| bodyElement = document.body;
| bodyElement.paintForeground = function(graphics) { ...
| draw something ... on top of <body> content
| ... using the graphics }
|
| This allows to benefit from both: retained mode (HTML DOM,
| layout cached) and immediate mode rendering - paint handlers on
| DOM elements.
| LASR wrote:
| The difference is in the programming model. The library itself
| is probably quite easy to support both models.
|
| If you have some UI in retained mode, chances are that
| rendering it live every frame will lead to unacceptable
| performance.
|
| But if you have UI in immediate mode, you can probably switch
| to retained - essentially lazy rendering until something else
| happens. But you'll have to be very careful that your render
| calls are indeed pure functions, and cannot produce different
| outputs unless some input has indeed changed.
| TazeTSchnitzel wrote:
| Do popular GUI frameworks that present an immediate-mode
| interface actually use an immediate-mode implementation under the
| hood?
| anderspitman wrote:
| The most popular immediate mode system I'm aware of is React,
| which definitely uses retained under the hood.
| ChrisMarshallNY wrote:
| That's cool. Thanks for sharing it.
|
| I tend to use the built-in framework (Swift native API). WFM.
| [deleted]
| keeganpoppen wrote:
| of course the first comment is someone "strongly" begging the
| user not to make a GUI library because they are "easy to get
| wrong" and "too big to be a fun hobby project"... i just don't
| get this mentality in programmers at all, but yet somehow it is
| rampant. i would maybe kind of understand this perverse form of
| insecurity / learned helplessness in the face of "complexity" for
| domains outside of one's training, experience, etc., but ... the
| _whole point_ of programming is the sense that you can do
| whatever you want if you just write the code correctly.
| otherwise, what the hell are we doing here?
| Retric wrote:
| It's not about helplessness it's understanding the difference
| between writing a toy _ over a week and the professional
| version is generally around 3+ orders of magnitude. Many people
| really don't understand that gap.
|
| I have worked with people actually trying to do several of
| these things like implementing RSA encryption from scratch, a
| charting library, and several other similar projects they
| assumed where going to be a quick solution. It's not that such
| projects are impossible, it's that people starting them
| generally have no idea what's actually involved.
|
| That said, if you're doing it for fun then feel free.
| amelius wrote:
| Perhaps it would have been more correct and more effective to
| write "there is no _money_ in rolling your own GUI library ".
| [deleted]
| baq wrote:
| Go ahead just don't waste other people's time (colleagues) and
| money (stakeholders) - there's opportunity cost to everything.
| DubiousPusher wrote:
| Very cool and as a lapsed GUI/graphics guy this makes complete
| sense to me. The bottleneck on guis is remastering and layout not
| cycling through the lists of sliders.
|
| How often you repaint or have to relayout should depend on only
| two things. How often is your data changing? And how soon does
| the user need to see that new data?
|
| Even things like moving the mouse or view are just data changes.
| (In fact, the biggest messes you'll get into when writing GUI and
| render code is when you've failed to incorporate something into
| your scene or data model and end up handling it with a lot of
| special case code.)
| bsder wrote:
| It's interesting because this matches every GUI that has to
| respond in real-time.
|
| If you look at _ALL_ the digital workstations, they 're doing
| their own rendering. And they all punt on text scaling.
| mleonhard wrote:
| How about an immediate-mode renderer that works like a Rust async
| executor?
|
| The executor could run all of the rendering closures on one core
| and benefit from caching.
|
| It could detect slow rendering closures and automatically switch
| them to buffered mode and run them on a "slow renderers" thread.
| This would keep the rest of the UI snappy. It could also tint
| those portions of the UI so users can see which app is the
| culprit of UI slowness.
|
| I hope that Rust can someday be used as the basis of an OS that
| does not rely on sandboxing for security, but instead uses the
| compiler to enforce security. Such an OS could use cooperative
| multitasking and use a lot less energy and less expensive
| hardware than our current multi-core CPU + MMU + kernel ring
| model.
| bhaak wrote:
| That's quite a feat.
|
| The best I could manage was looking for an error message when I
| had a problem with mp3 id3 tags handling, finding an unanswered,
| 4 years old question on SO which was exactly my problem and
| eventually answering it after solving it myself.
| kristianp wrote:
| The answer compares resizing performance of their application to
| spotify's Electron app, which has a chrome browser doing the
| rendering. Not a very fair comparison. I assume their thesis
| doesn't do that.
| bestest wrote:
| As far as I understand Spotify does not use Electron, it uses
| the Chromium Embedded Framework.
___________________________________________________________________
(page generated 2021-01-03 23:01 UTC)