ooh - didn't know it was possible to set an SDL window icon like that in a linux build, my project... updated :)
Show HN: Lite – A small, fast text editor
171–180 of 276 posts
Re: Show HN: Lite – A small, fast text editor
#172Earlier quoted context omitted.
Sites like github often "optimize" images to lower bandwidth costs. Basically any platform you share images on that is at scale will probably re-compress images. For PNG they often reencode the image in a lossy way.
GitHub doesn’t “optimize” your images, just as it doesn’t format your code. People would storm the barricades if Github changed their files.
They do change files that are embedded in readmes, just like most web platforms do. The original file is unchanged, but the version embedded in the readme preview on github.com is changed.
Re: Show HN: Lite – A small, fast text editor
#173Earlier quoted context omitted.
Yes, the rendering implementation uses gray-scale antialiasing. But system uses ClearType - compare rendering in window caption (rendered by Windows) and the text inside client area. Gray-scale may work on high-DPI monitors, but on typical monitors it will be blurry. But Apple and Microsoft still use ClearType even on high-dpi monitors. For that matter, Sublime Text, that uses similar architecture (but Python instead…
Apple removed all subpixel antialiasing on Mojave [1] and on Windows it isn't used for any 'modern' app using UWP onwards afaik [1] https://arstechnica.com/features/2018/09/macos-10-14-mojave-...
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.com/358596/how-to-fix-blurry-fonts-on-...
eventually, i will have to get with the program and buy a retina display. but i am thankful for this loophole that allowed me to put it off for awhile.
Re: Show HN: Lite – A small, fast text editor
#174Earlier quoted context omitted.
virtual DOM implies DOM existence. DOM based systems use so called retained mode rendering. But this one uses something that can be classified as immediate mode rendering. Check https://docs.microsoft.com/en-us/windows/win32/learnwin32/re...
> virtual DOM implies DOM existence No, it doesn't. I addressed this in the comment above. React's virtual DOM has been used to render: - Plain HTML (e.g. server-side rendering) - Native UI framework objects (e.g. React Native) - Text-based interfaces (e.g. Ink) - Smart TV devices (e.g. Netflix's Gibbon) - Browser ` ` elements - Markdown formatted text And a whole bunch of other targets. > DOM based systems use so ca…
> Native UI framework objects (e.g. React Native)
React Native uses DOM, the only nuance is that that DOM is a tree of native widgets/windows which is a perfect DOM.
Again, virtual DOM is a projection of real DOM in one form or another. It could be a tree of anything that can be represented by attributed nodes and leaves.
DOM tree has nothing with rendering and pixels, that's why "not even close". By using virtual DOM you can update (by diffing) some tree that even has no visual representation in principle - it is pure data structure. Think about abstract XML config that can be reconciliated with its virtual DOM.
Re: Show HN: Lite – A small, fast text editor
#175Earlier quoted context omitted.
Not even that: SDL just provides a pixel buffer, the application draws everything itself per-pixel. Lite uses a technique I refer to as "cached software rendering" which allows the application code to be written as if it's doing a fullscreen-redrawn when it wants to update, the renderer cache (rencache.c) then works out which regions actually need to be redrawn at the end of the frame and redraws only those. You can…
That's not anyhow different from typical GDI, CoreGraphics, GTK/Cairo way of doing rendering. Windows, MacOS and GTK maintain internal pixmap buffer for a window. And when needed you call InvlidateRect(wnd,rc) and receive WM_PAINT with cumulative rect to update. Personally, I would create an abstraction that wraps couple of functions of GDI, CoreGraphics and Cairo and use it instead manual pixmap rendering. Will be f…
It's quite different, actually, both in application programming logic and in expressive power of drawing primitives.
With dirty rectangles, it's the application's responsibility to minimize much of its drawing; the renderer will at best avoid copying bits where the target of the bits lies outside the drawing rectangle. The renderer can only optimize in situations where the entire call is understood as a full primitive, and it knows that the result will lie outside the dirty rectangle.
With rxi's approach, the application gets to define the commands which update the UI - which may be as complex as desired, as long as they have a calculable rectangle - and the cost of calculating that rendering can be skipped, without needing to query for dirty rectangles or doing any application-side conditional logic, beyond the layer that rxi wrote.
It's particularly powerful if the rendering primitives are higher level than those provided by the native APIs.
Re: Show HN: Lite – A small, fast text editor
#176Earlier quoted context omitted.
They are subjective in the degree to which they are measurable. How would you measure how well a text editor “integrates with a programming language”? There are many ways to measure this, making any single measurement choice subjective to a degree.
There is absolutely an objective process for identifying criteria and identifying how well it meets those criteria. First, an open-ended survey among text editor users to identify the features/requirements that matter to them. Second, tag and categorize those responses into a standardized list of features/requirements. Third, survey users to determine both the relative importances of those features/requirements, as w…
A survey doesn’t eliminate subjectiveness, it merely averages over it.
Re: Show HN: Lite – A small, fast text editor
#177Earlier quoted context omitted.
The resident memory was 10MB in my windows machine when I ran this. A strong reason for me to use this would be in a low powered device. I want to write markdown in a tiny editor like this. I want to run multiple projects side by side and this is good for that. If I'm a beginner trying do dev on a machine lower than 4G of RAM. So many more examples come to my mind. I'm pretty sure there are more Also the immediate UI…
On my GNU / Debian testing 64-bit, with 10 tabs opened it consumed 31 MiB of RAM and my CPU pushed itself to reach 0.75% at its busiest processing during typing. To me this is simply mind-blowing.
Not as mind-blowing as SublimeText leaking 3 solid GB of RAM after a few days on my Debian..
Re: Show HN: Lite – A small, fast text editor
#178Earlier quoted context omitted.
Sure, as native as any language that runs in a VM. There is no reason a WASM app can or can't be any more or less native than something running on lua (like in this case), jvm or anything else. People don't use Electron to get a js runtime, they use it to get a web-like runtime. Any javascript (including WASM) app can run without electron in either node or in the bundled runtimes that OSX/Windows/Gnome/Whatever has,…
Yes, and there is no reason you can't have a cow as a pet because they have pointy ears and a tail, like cats. It seems you've lost your way, my friend.
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?
Re: Show HN: Lite – A small, fast text editor
#179Earlier quoted context omitted.
Not even that: SDL just provides a pixel buffer, the application draws everything itself per-pixel. Lite uses a technique I refer to as "cached software rendering" which allows the application code to be written as if it's doing a fullscreen-redrawn when it wants to update, the renderer cache (rencache.c) then works out which regions actually need to be redrawn at the end of the frame and redraws only those. You can…
That's not anyhow different from typical GDI, CoreGraphics, GTK/Cairo way of doing rendering. Windows, MacOS and GTK maintain internal pixmap buffer for a window. And when needed you call InvlidateRect(wnd,rc) and receive WM_PAINT with cumulative rect to update. Personally, I would create an abstraction that wraps couple of functions of GDI, CoreGraphics and Cairo and use it instead manual pixmap rendering. Will be f…
Interesting. Do you know any software whose source code is available that uses such an abstraction to paint the screen?
Re: Show HN: Lite – A small, fast text editor
#180Earlier quoted context omitted.
What would you say are top open source editors one would consider, and by what criteria should one benchmark the comparison? While subjective criteria are perhaps most important (usability, integration with favorite programming language, extensibility), for technical quality perhaps there can be some meaningful numerical benchmarks. For example, the lag and memory use when opening a many-GB text file and editing the…
Personally, I'm thinking of its comparison to Geany. A wonderful editor but I have a feeling the first difference is it's going to seem real bloated. Time to see.
Geany is lean and fast but has some warts.
I.e. side-panel is too large, find+replace menu is modal and confusing.