It's too early to show anything, it'll be much more interesting once the 0.1 version releases, which will be in roughly 1 or 2 months. Hence the big warning in the readme.
This is why I use Firefox on mobile. You can install Ublock Origin, just as on the desktop. Plus it has reader mode, which is a godsend for some websites who don't optimize for mobile.
Well, I expressed my opinions on C++ libraries in the first few paragraphs. None of the C++ libraries I looked at support PDF layers for example (and as a graphic designer, you need that when working with maps, as maps are separated into layers).
QTPDF (used in QGIS) supports it, but the output quality is sub-par when working with Illustrator, at least in my experience. This could be a bug in QGIS, yes. But I didn't want to invest time into something that would probably fail (if the QGIS team failed using it, I would probably do so, too).
Well, as I said in the first sentence, the article is not only about Rust. I didn't want to write the next "memory safety is great" post, there are enough of those. I just wanted to present interesting problems and pitfalls I came across in 2017 and how I solved them using Rust.
The concern was quality, too. Yes, I thought about Electron, hell I even made a prototype for that. But in the end quality counts (to me), not speed of development. I knew that I had lots of time on my hands (no investors or anything, just my own money).
I didn't have anything to lose. So if you have the chance to make it perfect (versus taking some off-the-shelf tool and possibly ending up with a PDF that isn't quite what you want), would you risk it?
Very probably, but I feared that it was the fault of some framework they were using, so I wanted to stay clear of whatever they were doing. My library can export even huge PDFs in less than 500ms - but I have heard this "half an hour for a PDF" from other applications, too. I have no idea what these frameworks are doing. They seem to be accessing the disk a lot, like a lot. I noticed that the time for exporting a PDF went down (in my old company) when we switched to Macs that had an SSD. In my library, this wouldn't make much of a difference, since the document is first generated in-memory and then written out to the disk with buffered IO.
Users usually just blame their computer ("it's slow, let's grab a coffee"), but to me this performance is unacceptable.
1. I knew that I had a lots of time. From a business perspective, this doesn't make perfect sense, I know. I knew C++ (sort of) and was looking for a similar language. Learning Rust took me roughly three weeks (coming from C++), it is not as complex as you think. I think the time saved hunting down null pointers has amortized that investment greatly.
2. Again, I didn't know at that time if that was the fault of Windows. All that I saw was an application that was extremely slow, written in either C++ (with Win32) or .NET (both of which are possible). Second, the application had very shitty PDF output (ex. a shape with CMYK was "emulated" by four shapes drawn on top of each other, one for black, one for magenta, etc. - lead to a completely bloated PDF). I suspected that it was the fault of the framework they were using and I didn't want to end up in a similar situation.
3. Display is actually the #1 bottleneck. You have to understand that in a real map needs to draw roughly 10000 lines, fonts, and symbols. The old program (which I had to work with), did this using Win32 drawing routines. Every time you zoom in / out, it could take 1 - 5 seconds (if lots of things were on the screen). In OpenGL, I can do it in a sub-millisecond time (using this technique -
https://blog.mapbox.com/drawing-antialiased-lines-with-openg... paired with primitive restarting in OpenGL (https://www.khronos.org/opengl/wiki/Vertex_Rendering#Primiti...). ArcGIS, for example, has DirectX acceleration, QGIS uses OpenGL. This is simply a huge annoyance when trying to work with the program.