Earlier quoted context omitted.
I forked that to add support for Lua-based scripting, multiple buffers, etc. Fun exercise: https://github.com/skx/kilua
Hunter x hunter reference?
No, it was just the obvious "kilo" to "ki-lua" transformation!
Show HN: Lite – A small, fast text editor
251–260 of 276 posts
Re: Show HN: Lite – A small, fast text editor
#252Earlier quoted context omitted.
FWIW this is basically "dirty rectangles" which was a very common technique for avoiding full screen updates in games back when the hardware wasn't fast enough to do that.
It isn't. Normally the application needs to be aware of dirty rectangles; it fetches them from the window compositor, and it needs to limit its drawing calculations based on the dirty rectangle, in order to get the full benefit. (Dirty rectangles are still perfectly common in desktop apps for when you e.g. drag a window back on screen after overlapping the edge, or if you scroll a window.)
You are thinking about regions, dirty rectangles were a common thing in games to avoid redrawing the entire thing and rarely seen outside of them.
Re: Show HN: Lite – A small, fast text editor
#253Earlier quoted context omitted.
FWIW this is basically "dirty rectangles" which was a very common technique for avoiding full screen updates in games back when the hardware wasn't fast enough to do that.
Nah, it's tile-based concurrent precompositing , like web browsers do. Each tile knows what's in it (i.e. what set of DOM elements); and subscribes to state-change events for those DOM elements; and any such state-change event will trigger the tile to re-render its cached texture. Then, on each frame, all you have to do to draw everything, is to grab the latest cached texture from each tile, and blit those (or set th…
Like the other guy, you are thinking about regions (which is what the X11 DAMAGE / WM_PAINT / etc stuff use). Dirty rectangles is a method used in older games where the game kept track of -usually- sprites on screen and whenever something changed (e.g. a sprite moving) that part of the screen was marked as dirty (often implemented as a list of non-overlapping rectangles, hence the name). Dirty rects also flows only in one direction.
Re: Show HN: Lite – A small, fast text editor
#254Earlier quoted context omitted.
FWIW this is basically "dirty rectangles" which was a very common technique for avoiding full screen updates in games back when the hardware wasn't fast enough to do that.
You're equating the final stage of this approach to the entire approach. The point of this technique is that you get the benefits you typically would from dirty rectangles without the burden of the bookkeeping you would traditionally have. Using this technique your application "redraws" everything as if it's drawing it fresh each frame and the renderer cache takes care of determining what's actually changed. Typicall…
From the description at least it does sound there is book-keeping for the tiles so i'm not sure why you think there isn't such a burden.
Re: Show HN: Lite – A small, fast text editor
#255Earlier quoted context omitted.
well, apple certainly de-emphasized subpixel antialiasing. i am still using a non-retina monitor for all of my day-to-day work. when i first installed mojave, it made my display look so bad that it gave me headaches. so i wiped my mac entirely and re-installed the previous version of macos. later, i learned that subpixel anti-aliasing is still there, it just takes some fiddling to get it back. https://www.howtogeek.c…
I just purchased an HP Z27 (4K 27”) because I couldn’t deal with the low-res monitors I had at home. The high quality monitors in my office had really spoiled me. I’m so glad I did. Night and day difference.
It has become a challange to have a sane default for text rendering. Many users are still on really bad LCD monitors with low contrast. Macbooks also does 2x scaling. On a 4k monitor on PC i recommend fractional scaling eg 1.5 but as an app dev you cant control that. So do you increase text size to make up for the small pixels, or do you leave that up to the user.
Re: Show HN: Lite – A small, fast text editor
#256Earlier quoted context omitted.
KDE disables compositing when SDL apps are opened to improve performance. It should return once the app is closed. You can disable this behavior in System Settings > Display and Monitor > Compositor and unchecking Allow applications to block compositing.
Wow, thank you ! It's not the first time something like that happened to me but I would never have had the patience to investigate ! Can confirm unchecking that setting solved that problem.
This will have very bad effects when playing video games and might(?) potentially increase battery usage when watching full screen videos.
Compositing should only provide the fancy effects like Wobbly Windows and window previews in the alt-tab switcher etc. Not sure why this is causing KWin to crash... You can use Alt-Shift-F12 by default to toggle compositing.
But if you're not doing anything more graphically intense than playing turn-based or slow-paced video games then I guess you can use that option to permanently leave on compositing.
Re: Show HN: Lite – A small, fast text editor
#257Earlier quoted context omitted.
Why is using JS or WASM as a building block for a app any worse than lua, python or ruby? What is the material difference?
The material difference is that this editor is an order of magnitude smaller than a browser. Sure, you can go "we have plenty of RAM/storage/battery these days", but consuming 10x more of every resource you can think of is quite the hint that you are not using the right tool for the right job, or that you do not employ the right person for the right job.
That's not because of JS or WASM, that's because of the browser. Using JS or WASM does not mean you need to use a browser, you can for example run quickjs, node or whatever other runtime without bundling a browser.
This editor could have been written in js and use the exact same libs for rendering. If it used one of the smaller js runtimes (like quickjs) I'm guessing it would have been similar in size and pretty close in performance.
I don't get why you are conflating using a certain language with bundling a full browser (like electron does). It's two completely different things.
Re: Show HN: Lite – A small, fast text editor
#258It seems a lot faster than most. But what it still doesn’t replace is my favorite editor EmEditor [0] (Windows only). Like every alternative I’ve checked out, Lite blocks for a long time when opening a multi-gb file. They aren’t FOSS and probably more expensive than any other text editor, but I’d love to know what they do to have such superior large file performance (the free version is fast, the paid version even su…
Wow, thank you for mentioning EmEditor, I used to keep it as a must-have app when used Windows, preferred it over UltraEdit, EditPlus etc, good memories. Nowadays it's all vscode though.
Re: Show HN: Lite – A small, fast text editor
#259Earlier quoted context omitted.
> A virtual DOM doesn't necessarily imply DOM existence; That's wrong. virtual DOM is always a parallel structure to real DOM - projection of it. That's by definition of it. From vDOM authors: https://reactjs.org/docs/faq-internals.html > The virtual DOM (VDOM) is a programming concept where an ideal, or “virtual”, representation of a UI is kept in memory and synced with the “real” DOM
I get the feeling you're reading this too literally. I think eyelidlessness is talking about using a technique that is analogous or similar to that of a virtual DOM. Nobody is talking about an actual DOM.
That was my intention yes.
Re: Show HN: Lite – A small, fast text editor
#260One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not. What are they talking about!? I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over doub…
I use vim as my primary editor. I've tried a number of times to pick up VSCode. The functionality is there. The modal keybindings are there. But yet it lags and I can deal with it in the short term but over the course of a day my frustration mounts and I end up going back.
There's a difference as well between refresh/frame rate and input lag. It is very much possible for a game to have a consistent 60hz frame rate but yet lag. Lag can come from delays in the input subststem, it can come from buffering before display, it can come from the display itself.
Here's a good read: https://www.eurogamer.net/articles/digitalfoundry-2017-conso...