Show HN: Electro – A hyper-fast Windows image viewer with a built-in terminal | Hacker News Reader

Show HN: Electro – A hyper-fast Windows image viewer with a built-in terminal

github.com

46 pointsTinos40 comments

This is my first major OSS release! I was always so frustrated by how slow image viewers were on Windows so I built one from the ground up with Rust & Tauri v2.0!

Electro also has a very unique feature: a built-in terminal. I was always mesmerised by merging CLI tools with GUI based systems and this is my first go at it!

I have big plans on expanding the terminal functionality with built-in image editing commands, command chaining, file handling etc.

Open articleView on HN

That's fast! It seems even faster then using mpv, even though you can't use it like this from the command line.

mpv *.jpeg --shuffle --loop-playlist --image-display-duration=2.0 --fullscreen

I remember, 30 years ago there were similar ultrafast image viewers for DOS, they didn't even need windows. I was partial to QPV/386, but there were others. Linux console has fim. It was great to be able to zoom and pan with the keyboard.

https://www.nongnu.org/fbi-improved/ https://www.oreilly.com/library/view/png-the-definitive/9781...

Being able to launch Electro via CLI would be awesome! Never really done something like that - might have a look at implementing it (unless you want to contribute :^)

The project is in its infancy at the moment. Features like keyboard controls to zoom etc. are all on the table - I love when users give me all these ideas for where to take the project

I share your frustration so I love that it is so fast/lightweight, cool project. I personally don't think I would have much use for a built-in terminal. I would just like for it to let you browse through whatever other images in the same folder from the image I opened with and be able to navigate it with the keyboard.

Images should also resize whenever the window is resized. Those two changes alone would make this very usable.

Thanks for the constructive feedback - the folder feature is 100% coming soon, it was one of my favourite features from other viewers as well.

I'll create an issue for the resizing, good spot!

Feedback is always greatly appreciated :))

> I was always so frustrated by how slow image viewers were on Windows

Irfanview was always my go-to for speed on Windows

Loved Irfanview, switched to ImageGlass for aesthetics (hated the performance), switched back to Irfanview, hated how ancient it felt.

Electro aims to do what an image viewer should do best - show images. There aren't any UI elements when an image is first loaded - hence the hidden terminal (pack a lot of functionality without worrying about visual clutter).

I have been carefully thinking about the direction I want to take with UI elements. The goal was to build the fastest & most efficient image viewer. Will I achieve this through clickable UI elements? Through keybinds only? Through terminal? Only time and testing will tell.

The project is fresh out of the oven and ready to be moulded into whatever the community wants it to be. The two mantras Electro will always stand by are Performance & Efficiency.

Thanks for the thread - loved reading everyone's thoughts.

P.S JPEGView was by far my favourite but again, too ancient. I want something truly fresh and that was the goal of this project

Try JPEGView - it is much faster than Irfanview for looking through a folder of images. Either preloads or has a better rendering engine, or both.

Make sure to get the currently supported fork, not the original.

Same. Will be interested to try the new tool but it would take a lot to unseat Irfanview for me.

check out kpic from Ken Silverman: https://www.advsys.net/ken/utils.htm

Another vote for Irfanview from me! Is there an app like this for MacOS?

Or you can restore the Windows 7 image viewer[0]. Works on Windows 11 still.

[0]https://www.tenforums.com/tutorials/14312-restore-windows-ph...

I generally love the Win7 era stuff better than anything that's come since, but I always struggled with the image viewer. Pressing the keyboard hotkey for "next"/"prev" (right/left?) it always seemed to randomly lose focus (without me tabbing to another button or anything) after a few times, and I'd have to grab my mouse again and cursor-click the button.

Cool! Any plans for linux/macOS?

I’m currently using oculante specifically for its speed, rust and cross platform.

Not sure this electro viewer is for me, as I see typescript and css frontend.

Would absolutely love to get linux & macOS included. I don't own a mac so naturally that will need to be community contributed / wait until I cough up the money. Linux is 100% on the agenda.

Thanks for bringing Oculante to my attention - it looks awesome! That level of functionality is what I'm striving for (w/o as much UI clutter though).

I feel the TS & CSS pain. Electro v1.0 was C# WPF and very very very fast but the UI was just rubbish and I knew C# WPF would hold me back in the future. Electro v2.0 was then written in C++ but I didn't get far with it because I REALLY didn't like writing C++. Electro v3.0 was then written with Electron + TS + CSS but electron is shit. Finally, I landed where we are today - it struck the perfect balance of performant, modern language, fun to write, allowing for rapid iteration.

Will Electro stay with the TS+CSS+Tauri stack forever? Probably not! As the community grows I hope bring in contributors who are more well versed in the world of low-level image viewers to help guide Electro to be EVEN FASTER & closer to the system level (Like Electro v2.0 aimed to be w/ c++).

For the time being I've decided to just ship with what I have and iterations will come later. I do dream of the day we go frameworkless (to an extent ofc) and render everything from the GPU at nanosecond speeds while also maintaining the sleek feeling Electro currently has!

What UI clutter does oculante have in Zen mode?

Is it really "hyperfast" if it's just opening a microsoft edge webview window?

Is it really faster than the image viewers made 20 years ago that open a window with the win32 API?

So this is a hotly debated subject and I 100% understand why and even agree with many people on this. I do firmly believe that Electro is indeed "hyperfast" even with WebView2 and that's down to the fact that there is absolutely zero bloat shipped with the tool & every addition is carefully considered for its potential performance impact before it's added.

I had a meeting today with 6 other software engineers who are interested in the project & have experience in computer graphics (a topic I will admit is not my strongest) and we all unanimously agreed to gradually shift Electro away from WebView2 and towards a custom-built 2D renderer for truly native "hyperfast" performance :)

As mentioned in another reply on this thread, I'm not here to fool anyone - this is version ~4.0 of Electro and the first version I feel is feature rich enough to ship publicly. The other 3 versions of experimentation (over the last year and a half) included Rust, C++ & OpenGL, Electron, and Tauri all of which had significant pitfalls.

The final decision was to "just ship it" and see how the community reacts. I've seen (as I anticipated) a huge number of people suggesting we move away from Tauri and that's exactly what we will do.

Open sourcing this project was keeping me up at night because deep inside I knew that it would need another version. That being said, I'm so glad I did it or else there would not be any pressure to actually do it and it probably would have ended up just like all my other dozens of projects that are just sat in private repos collecting dust. At least now with this version people can A) Enjoy using a new tool w/ unique features (built-in terminal, performance focus) and B) Even contribute if they feel like doing so.

I'm very excited to see where this goes but the compass is very clearly pointing towards ultra low-level rendering techniques and I honestly can't wait to set sail!!

I do firmly believe that Electro is indeed "hyperfast" even with WebView2

This is a very passionate reply that does not answer the question or address it with numbers or any technical information.

that there is absolutely zero bloat shipped with the tool

But you're opening a web browser and calling it "hyper fast". Why not just set windows to open a web browser?

we all unanimously agreed to gradually shift Electro away from WebView2 and towards a custom-built 2D renderer for truly native "hyperfast" performance :)

Gradually shift away? Custom built 2D 'renderer' ? What are you even talking about here? Just open a window and copy pixels into it. Resize the image using a 2.2 gauss kernel. This stuff was solved decades ago.

A win32 API opens instantly, FLTK opens instantly (and has a jpeg library built in), irfan and xv open instantly.

The final decision was to "just ship it" and see how the community reacts.

The combination of calling your own software "hyperfast" with no actual numbers or comparisons is pretty egregious and people were pretty easy on you after claims like that.

Just a reminder that this is *free* open source software. I understand your concerns, and I agree with some of them. This is my first proper open source project so there are bound to be some issues ¯\_(ツ)_/¯

I will take your advice into account for future updates. Thank you

Free and open source is great, but promotion is valuable, and claiming you did something significant when you're just opening a web browser is minimally pulling a fast one on anyone who took this at face value.

How is it that the preview-videos showing how fast it is, is still slower at loading small image than it is for my old desktop to START feh AND display the window and image ?

Does anyone know a similar image viewer but that manage correctly the colorspace of the image and the colorspace of the screen ?

Dumb question, is there some kind of "tiles" view to quickly scroll through a directory of photos?

Not yet but 100% a feature we can get shipped (seems to be pretty high demand)

How does this work with large (i .e. ~30,000 by 40,000 pixel) 16 bit TIFF images?

Naturally images of this magnitude will take slightly longer to load on any hardware & image viewer. It's not instant but it's also significantly faster than the other image viewers I have tried on my system.

I downloaded NASA's photos of the moon and tested those with wonderful results. I was actually using these enormous 16k+ images during my testing specifically because they are the ultimate benchmark for image viewer performance!

Awesome, thanks. I’ll give it a try. Nice work.

Thanks a lot for your project. Have you compared the speed with JPEGView?

I haven't been able to do direct comparisons but they most likely have very similar performance. The major bottleneck with Electro at the moment (which will certainly be addressed on Electro (internal) v5.0 aka Electro Next) is the reliance on Tauri & WebView2.

As soon as I can port over core functionality to a custom desktop renderer things will go from being 10x faster (currently) to 1000x faster (the end goal).

I'm currently trying to balance Electro with: university final year, job applications, 2 other OSS projects I contribute to, and a friends' business website so these features will most likely take many months to get through. I'm hoping the eyes Electro has gained from this announcement will bring in some talent who know more about lower level image viewer functionality than I do so that they can help guide the project towards the ultimate performance-first tech stack!

Thank you.

> As soon as I can port over core functionality to a custom desktop renderer things will go from being 10x faster (currently) to 1000x faster (the end goal).

That sounds like quite difficult job? Do you know any other projects that do the same?

I believe most of the popular image viewers you'll see discussed in this thread will be using very low-level renderers.

I'm in discussions with friends of Electro on what approach would be best to take. I go into more detail on this announcement made on the discussions board: https://github.com/pTinosq/Electro/discussions/17

"Hyperfast" should show the startup time vs another app.

Why does Electro make multiple web requests on startup? Why does it need to make any?

And forcing windows to make your app a default, without asking the user about it at install time - not cool.

Hey! Appreciate the concern w/ web requests. If you look closely at the URL you'll notice that all the requests are to *.localhost addresses. This is just how Tauri's asset handling & IPC systems work - nothing to worry about :)

I've gone ahead and create a GitHub Issue about setting up a checkbox with the installer such that it doesn't force Electro as the default app. It's something I wanted to add pre-announcement but figured it wouldn't be as much of a requested feature as it clearly is, my bad.

Thanks for the feedback!

Nope. Very first request it makes:

From: Microsoft Edge WebView2 To: 13.107.42.16:443 - Redmond, United States of America

(very handy tools, per-application firewalls..)

Oh bloody hell of course Microsoft is pulling off stunts like this. Thanks for raising this, I'll have a look at what my options are to turn this off.

Tauri 2.0 was initially chosen because it would let me get an MVP out quickly to start getting user feedback (like your own). My end goal is to move to a custom renderer so I'm not relying on Chromium / WebView2. This will take many months of work I suspect (balancing with my FYP @ university & other projects).

Here is a whole story: https://github.com/tauri-apps/tauri/discussions/4089

tl;dr - Tauri uses platform's default implementation of a webview. On Windows it's WebView2 which reports back to MS.

Can you show others how you did this in a post? Truly neat

This? Finding outbound/inbound requests to an app?

Not sure it's worth an entire post. But:

The application in question is NetLimiter for Windows https://www.netlimiter.com/ (I'm sure there are others, btw)

It acts as a per-application firewall. It also has the ability to block internet access completely, as well as Priorities (bandwith allocation) per application.

By default it will pop up a window every time an application makes web requests, either inbound or outbound.

You have the option to Deny or Allow the operation. And options to have that be temporary (next x minutes) or permanent.

After being set up an alarming number of applications will cause NetLimiter popups, but very soon everything will either be allowed or blocked.

So I spoke to one of the contributors of Tauri who got back to me with the following response: " It's not a thing tauri controls and the telemetry settings are an operating system setting since you are running windows this kind of telemetry is not completely avoidable."

He also kindly pointed to this GH Issue which discusses your privacy concern: https://github.com/MicrosoftEdge/WebView2Feedback/issues/105...

This quote from the issue stood out in particular: " WebView2 is considered a Windows component, and the data collection consent is governed by Windows Diagnostic setting on Windows 10 as a centralized switch.

End users are empowered to control the data collection of WebView2 and can do so via toggling the Windows Diagnostic setting on Windows 10. This is also what the Edge browser does. On Windows 7/8.1, because there is no Windows Diagnostic setting, we treat this as no consent for optional data. There is very limited required data that the OS always collects, unless you're on some specific SKUs. Developers are definitely welcomed to convey that to their end users and ask them to use the OS toggle. "

I've been meaning to move away from Tauri + WebView2, this might be the best call to make (not only for this reason of course)

Reply on news.ycombinator.com