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. |
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...
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
Images should also resize whenever the window is resized. Those two changes alone would make this very usable.
I'll create an issue for the resizing, good spot!
Feedback is always greatly appreciated :))
Irfanview was always my go-to for speed on Windows
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
Make sure to get the currently supported fork, not the original.
[0]https://www.tenforums.com/tutorials/14312-restore-windows-ph...
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.
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!
Is it really faster than the image viewers made 20 years ago that open a window with the win32 API?
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!
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!
> 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?
And forcing windows to make your app a default, without asking the user about it at install time - not cool.
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!
From: Microsoft Edge WebView2 To: 13.107.42.16:443 - Redmond, United States of America
(very handy tools, per-application firewalls..)
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!!
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.
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
I will take your advice into account for future updates. Thank you
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).
tl;dr - Tauri uses platform's default implementation of a webview. On Windows it's WebView2 which reports back to MS.
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.
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)