ULV Pictorial Development Diary (56k die)

[Fred]

This thread is here to document development of ULV from its inception through to its current state. The natural evolution of a hollow skeleton with barely working test code to a fully fledged world-beating application. We're not at the end of that yet, so expect this thread to keep growing over time.

This will mainly be a pictorial thread. I'll try to keep the pics per page count relatively low.

Before I started coding I had been thinking about this for some months. I even have one screen shot of that thinking process, so here it is, in the first post:

A rare piece of early ULV history from Mar 22 2013:

Code: Select all

Carefully hand drawn using the touch pad on the old faithful Macbook Air and an app called Paintbrush.app. There were other sketches and notes predating this, but on paper :-)

I started off writing some back end libraries from ideas before I even dreamed of ULV. The back end libraries were unused until ULV, and had purely been written to an idea, with no tests and no real world usage. When I finally did include them later in the game for ULV, they worked pretty well. I did need some API changes to make them effective, however they're very usable now.

Currently the app uses less than 20% of the memory that OLV does for the same FreeEMS binary file. In fact, it actually uses less than the binary file does on disk. Magic? No, simply good design. It's also more than four times faster to load the data up. Additionally, there is no math done during zoom operations, so it's fast there too. It's fast and lean *everywhere*, by design.

On with the pictures! Comments here: http://forum.diyefi.org/viewtopic.php?f=40&t=2134

Fred.

[Fred]

This one is from Mar 24 2013 and shows some trace drawing code working. This code I had also previously written just to lay out the required logic, in isolation. I was bored that night, so just pulled those files into a random piece of swing code off the web and executed the code in that context, and it worked 100% fine.

[Fred]

My initial focus on the app after these first tests was to come up with a suitable structure for a flexible application. One thing I never liked about OLV was that if I needed more than one, they would fight over the config file. I regularly have multiple files open at the same time for various disparate reasons, so, from the start, ULV was intended to support N windows, and a stay-alive model. This shot is from Mar 27 2013 showing my idea of a quick access file listing menu to allow browsing of your data log library and opening whatever you choose into a new window.

[Fred]

Another thing that I've been after forever is resize-able divisions, particularly for logic traces like sync and fuel pump, and so forth. This was, therefore, also high on my list of things to achieve. So it was done very early on, and on Mar 28 2013 I uploaded this:

[Fred]

By Apr 3 2013 I had started to get serious about things and had multiple resize-able divisions available in multiple windows, the dream was becoming reality:

[Fred]

I quickly noticed that resizing the divisions into smaller matched areas was a massive pain in the arse, so I developed size matching, if you add one at one end or the other, it mimics the one that was already at that end. Uploaded April 5th 2013:

[Fred]

I was concerned about excellent visual and interactive performance from the start, so I created a new view component that drew some random squares and did some performance tests on different sized windows. One of the tests that I did was without background rendering, so rather than some randoms squares, the colours built up at several hundred frames per second and rapidly grew into what you see below, uploaded Apr 6 2013:

[Fred]

It wasn't much fun staring at black/grey divisions all of the time, so I took that same tiny hard coded snippet of data (about 20 records long) and referenced it from each division with a colour pulled from a fixed list, index incrementing each time. This was the result, note matched sizes from the four bottom and two top divs. Uploaded April 7th 2013:

[Fred]

On all platforms, the right thing to do is to let the OS position the window. However the JREs on Linux are fairly broken, and to avoid some bugs for most users (sorry Tiling WM people, your own fault, and/or Sun's/Oracle's) I had to do the positioning myself. To stress test this, and ensure windows never ever fell off screen and unreachable, which is possible, I did this, uploaded April 9th 2013:

[Fred]

The next thing I did was upgrade my fake data. I added a variety of patterns and made them 192k records long. The number, type, and colour of traces was randomly chosen. I played with that a bit, and these four images from the 11th of April 2013 reflect the outcome of that playing: