Stefano Tommesani

The AltaLux plugin for IrfanView is now open-source (here is the GitHub link) and it is worth analyzing the different methods used for parallelizing the computational kernel. The filter factory, contained in the CAltaLuxFilterFactory files, can create one of four possible instance types (actually there's a fifth one that you will never want to use, as we will see later). Most of the plumbing code is hosted in a base abstract class, named CBaseAltaLuxFilter, and there are four specific classes that implement the virtual Run method in different ways:

1. CSerialAltaLuxFilter
2. CParallelSplitLoopAltaLuxFilter
3. CParallelEventAltaLuxFilter
4. CParallelActiveWaitAltaLuxFilter

Let's start with the first one, the serial implementation, to have an idea of how the code works. Here is the whole Run method:

Dependency Injection (DI) and Inversion of Control (IoC) are popular patterns in modern software development that reduce coupling among modules and so improve the testability of the sames. As this article is not meant to be an introduction to DI / IoC, please refer to numerous introductory articles on the net before tackling this topic, as we will delve straight into the implementation's details. For these samples, we will use Castle Windsor as IoC container, and we will build the same sample three times, highlighting the differences in handling permanent and transient class instances with an IoC container. The aim is creating an implementation that has minimal coupling and is highly testable. 

Let's start by drawing the scenario: our simple app uses the IoC container for cross-cutting concerns, in this example only logging but in a real app there could be a lot more functionalities of this kind. e.g. data model access, telemetry and so on. The logging framework is a singleton that spans the whole life of the app, so once we register the interface in the IoC container, and let the container inject the instance into the objects that use it, we are golden. But temporary objects, like a child window, are created and then destroyed when needed, so the same instance cannot span the whole life of the app. At the same time, these temporary objects need to access the functionalities such as logging, so those instances must be injected into the freshly created object.

Let's start with the first implementation to see some real code (before proceeding, download the whole solution from GitHub). The project ManualIoC contains a poor man's implementation of DI, as we have to manually pass the instances to the transient objects. First, let's start with the main program, where we initialize the IoC container:

static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
 
            // create IoC container
            IWindsorContainer container = CastleContainer.Instance;            
            container.Register(Component.For<ILogger>().ImplementedBy<ConsoleLogger>());            
            container.Register(Component.For<MainForm>());            
 
            //Application.Run(new MainForm());
            MainForm mainForm = container.Resolve<MainForm>();
            Application.Run(mainForm);
 
            container.Dispose();            
        }

There are several changes compared to a stock WinForms application: before creating the main form of the app, we create the IoC container, and we register the implementation of the ILogger service, and the MainForm class. Instead of creating directly the MainForm like it happens with the standard WinForms code, we ask the IoC container to resolve, that is returning an instance of the given class, the MainForm and then we run the application. The critical bit is that MainForm requires an ILogger instance in the constructor, and the IoC container knows about it, so it transparently creates a singleton for the ILogger interface using the ConsoleLogger implementation and passes it to the constructor of MainForm, without requiring any intervention from our side. With a simple demo it is hard to understand how an IoC controller can simplify a real project, but assume that there is not just one cross-cutting functionality like logging in the example, but many more and you will understand how the code gets clearer and simpler. Also, rewiring the app to use a different logging framework requires just creating a new implementation of the ILogger interface that uses the new framework, and changing just the registration of the ILogger interface in this bit of code.

I have just released the new version of the AltaLux plug-in for IrfanView on GitHub, clone it now!

There are some good reasons for taking a peek:

• having a look at how to write a plugin for IrfanView
• discovering how the AltaLux algorithm works
• comparing different ways to divide the computation kernel in various threads

And don't forget to download the new version of the plugin, in both 32- and 64-bits versions, from the download section!

We recently heard about two really far branches in our codebase. Your mission, should you choose to accept it, is finding the changes and merging them.

So I try a GIT diff within Atlassian SourceTree, my GIT client of choice, and the result is unusable: the developers not only made a lot of changes within the same functions, but they also moved functions across the source file, and diff is trying to reconcile different pieces of code that have some similarity.

Enter WinMerge. More or less, the result is comparable to what I had with GIT, back to square one.

After a search on the net, I have found DiffMerge from SourceGear. Running it on the same code, I got a vastly better result, as it recognizes that is parsing C++ code and seems to use function definitions to resynch changes, this way avoiding reporting similar lines of code from different functions as a match. Of course, it does not track functions moved across the source file, but it is fairly easy to spot them, as they appear as code blocks appearing only on the left or right column in the trackbar on the left.

Mission accomplished!

#1 of 100 in Professionals like me