So I had pretty much took on this interesting task of seeing what functionality can I implement (and somewhat well) for the sole purpose of really learning to master C# & .NET Framework & Concurrency. However I seemed to have made some good progress.
My search online to see how I can speed up my background worker thread lead me to this website which really demonstrates (most likely to the joy of C++ fan boys) how much managed code can really slow down performance. Pretty much by having direct access to the memory we can alter it faster than through .NET runtime. The author explains it nicely:
Locking the bits keeps the .NET runtime from moving them around in memory. This is important because we’re going to use a pointer, and if the data is moving around the pointer won’t point to the correct thing anymore. You’ll need to know the pixel format of the image you’re trying to convert. I’m using jpeg’s, which are 24 bits per pixel.
Not everything however was nicely explained or perhaps they are thought to be trivial. I was for some reason under the assumption that ARGB would be stored in that order. Such that every byte follows that pattern as I increase in memory address.
With a little debugging I discovered how the order is in fact in reverse (BGRA) and perhaps some head scratching makes me think it’s probably that way since the file was written in Little Endian
How everything comes to together
I guess it’s funny how things relate and pop up so qiuckly. It has been perhaps only a week since I had read and written the splash code that makes use of the Invoke() method so that methods can be run on the same thread as the Window and yet during this side project I forgot totally about it (for a little bit at least). I was trying to update the Image in a PictureBoxControl in the background worker thread and wasn’t sure why the image wasn’t updating. It only took a few mins to remember that I needed to marshall into the proper thread.
The speed has already greatly improved and this is performing the calculatoins on a single thread which leaves the possibility to come back to the threadPool class which I might need to do if I want to get the RGB sliders as responsive as I’d like.
So trying to learn a bit about concurrent programming prior to my class next semester and thought a good way to learn would be to write a simple application. Kinda odd how simple apps seem to grow so quickly into something that is beyond my scope of knowledge.
I wanted to originally write a simple image manipulation tool, as I thought it would be neat to look into really basic manipulatoin and try and perform them on separate threads. I had initially thought of doing it somewhat similar to what I head learned in CS370 of breaking the image into smaller images and offloading the processing onto small threads. There seemed a pretty good class offered in the .NET framework for this sort of thing; the threadpool class.
However nothing turned out as I had expected and trying to use the threadPool class was nightmarish. I think partially the reason may be is that I am not setting up the image object properly so that multiple threads can access it. I guess the two approaches were either:
Manipulate the actual image file and refresh the component with the new image every time a thread is done executing
Manipulate the pixels that are actually being displayed.
Either or it didn’t seem to work.
Decided to scale back my attempts and just decided to go for a 1 thread (backgroundworker) approach. I had succesffuly done grey scaling (which was neat to learn on how something so simple can actually be pretty intense if you want to make the greyscale perfect). I had chosen to use the values :
I then tried to put RGB sliders, however I seemed to have hit a wall in making the sliders feel really responsive. I guess I would appreciate help from anyone if they have any ideas on how to do it.
The computer at my current job is pretty slow and compiling the WinForms application we are developping not only takes forever to compile but to load as well since there are so many asm files to be loaded.
I decided to write up a nice splash screen for the application which will show the current asm being loaded. There is a lot of resources on the net however I found this to be the best article . Other people were placing the splash screen on the same thread or using it to report on initializatoin of the actual application whereas I was looking to have a splash just for the asm loading.
I had initially started with a really stripped version of my current implementation seeing a lot of what the original poster had done as being too complicated. However I either rushed my implementation or it wasn’t explained properly the reasons behind certain code choices.
One issue of the code I was confused about was the Invoke() and delegate creation for something as simple as setting the Controls.Text proprety. It was interesting learning how a Control’s propery are thread locked which after reading a bit seems to be a feature added in 2.0. The Invoke() command executes the method on the thread that created the Control. The result of using the delegate in this manner is thread-safe UI modifications. Pretty neat feature, otherwise might have needed to add Locks to the property for thread safety.
Things I would like to add to my splash screen:
I was looking into not only adding a label of the asms’ being loaded but displaying a progress bar. I was wondering if it’s possible to build the asm reference list of asms to be loaded so that upon each load I can make an accurate step in the progress bar.
My first real foray into world of programming was through the use of Java (I had done some Turing but that doesn’t count). Therefore I would say my initial teachings of computer science are heavily object oriented with principles in design patterns. I remember first learning of the most well known design patterns (observer, singleton etc…) and thinking to myself what a great a tool I know have at my disposal. However did I fall into the pit trap of seeing every problem as a nail now that I have found my hammer?
Its corporations and business who want you to think in design patterns, so that they can make money. In functional style a design pattern is simply a higher order function. Everything is much much much more light weight. Design patterns are not extensible and often non composable. One you choose to use one of them you are stuck, for the rest of the life of the application. Design patterns are top-down approach and therefore they “claim” they know the “future” of the application. Since no one can predict how an application will evolve, forget about top-down design and software architects. Software arichtects means incompetence. Use bottom-up and no-patterns.
The above quote I read while looking into ideas for an undo framework for an application I am developing at work. Although I understand/comprehend the point of view I’m not sure I have been swayed. I have not written much in large scale applications but if there is a point where the design pattern used no longer fits the application it would seem that the application itself has evolved into something quite different.
Not sure how far to go into the subject; but rather stick to the point of “Is heavy OOP always the right way to go ?. For now I never mind setting up the overhead that is OOP.