Fireballs and ToolTips

So this probably my first none software related post ( /hurray?). Anyways I’m still learning and tinkering around with WordPress (will probably eventually change to a custom theme) and learning PHP.

You might have noticed I had just installed Now Reading Reloaded plugin, so that I can attempt to try and keep track of books I have read/reading. Will add the large list of books I have already read soon.

I have just finished reading Raymond E. Feist’s new book “Rides a Dread Legion”. Although not the best book he has written, it is still quite good (and I am pretty thankful he is still writing additional novels). I think the problem for me is that Pug&Party have just gotten so powerful that I am just surprised when something exists that can even be bothersome to them. This novel had introduced the new spell lore of Demonology; one of the key reasons for my enjoyment of the book. It was very interesting reading the experiences of someone who had through trial and error mastered the art vs. through studies.

Tooltips

What is people’s fascinations or rather intrinsic need to desire everything in a user interface to have a tooltip? I really value the information most tooltips provide however I think that there are a lot of applications (including the one I am developping on) that have gone to far to place a tooltip especially when it is unneeded.

Today I noticed one of the applications I have been using has tooltips for the “OK” & “Cancel” buttons, with the tooltips saying “OK” and “Cancel”as well.

This really brings up an issue taught in my User Interface course to build user interfaces under the assumption that every piece of software you will write can be assumed to be operated/used by someone who has the IQ of a shovel. Where has the idea of developping for power users’ disapeared to? I understand the benefits that developping for all users in an attempt to achieve a curb-cut phenomenon, however the choice to develop a lightweight/simple implementation designed for power users seems to be neglected.

Trying to get feedback faster than you can say…

I must be tired trying to work on the RGB sliders because I don’t seem to be thinking straight. I’m beginning to think that with only one background thread it may be very difficult to get quick response even with the upgrade to the code using unsafe even with my little test images (forget it for sure working with large ones).

I’m spawning a background thread (don’t mention the overhead 🙁 ) everytime the slider changes which begings the method to alter the red value of each pixel rather than “reset” the single thread which didn’t seem any better.

I have to get some actual times down to see if this is even better than just using one single background thread and cancelling the operation everytime the slider changes.

Anyway here’s some of the code so far of my sort of weak attempt to get fast feedback:

Let there be red
Post any help if you have some.

Side Stuff

I guess I’ve made a lot of posts which are really really software oriented versus rather than some other stuff I’ve been doing lately (squash, ice hockey) I just found this project to be really interesting and on my mind.

Part of what is so interesting is noticing how a project envisoined initially so small can just explode if not checked. I seem to be working just as hard to fight thoughts to add the application than I do actually working on it. I guess that is what the benefit of programming something for an assigment versus than for you is. You tend to not go beyond the scope of the assignment, whereas for yourself you let your thoughts run free.

I feel this is something it is good to get a grip on. It seems to be a big problem some people lack in the software industry especially evidently from my current and previous jobs. People never want to freeze the software and label it feature complete; but rather seem to happy tacking on feature after feature.

Image Manipulation Tool Me Some More

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.

Threads and Images

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:

  1. Manipulate the actual image file and refresh the component with the new image every time a thread is done executing
  2. Manipulate the pixels that are actually being displayed.

Either or it didn’t seem to work.

Scaling Back

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.

Here is the application with an image greyscaled.
Here is the application with an image greyscaled.

Splash Screens

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.

Locked in for life?

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.