lonetechie.com
one techie, trying to make a difference
Preload images in IE6
Jan 14th
I spent a significant chunk of time today diagnosing an image preload bug with IE6. Bug probably isn’t a fair word, but for a browser that is one big bug why not. In short preloading worked as it should in every other browser I test against except for IE6. IE6 would preload the image, onload event fires, I set the src for the image and it continued to download the image again!
Doesn’t work
pic1= new Image(); pic1.src='/image.gif'; pic1.onload = function(){docimage.src='/images.gif'};
Works
pic1= new Image(); pic1.src='http://site.com/image.gif'; pic1.onload = function(){docimage.src='http://site.com/image.gif'};
*sigh*, who would’ve thought. You MUST have the full path in the src link or IE6 won’t preload it. It really crossed my mind today to just bite the bullet and not support IE6 at all. It still appears that about 25% of our visitors are IE6. Don’t even get me started on the hoops I have to jump through because of no png support.
Cuil isn’t so cool anymore
Dec 19th
So for those that aren’t familiar Cuil (pronounced Cool) is a start up search engine founded by some former google employees. With a pocket full of venture capital funds they set out to compete with the big G. My initial response to this was, “Great, finally some really competition to google”. Sadly the opposite has been true since Cuil has hit the map. July 2008 I gave Cuil an honest rundown and was simplynot impressed with the results. Most notably is Cuil’s attempt to provide images next to search results. What I found amazing about this is they simply would show images that not only didn’t reside on the site the link pointed to, they didn’t have anything to do with the result at all. This fact alone is a mammoth failure. Even today (nearly 6 months later) nearly every page has an image that really shouldn’t be there.
Getting past the borked image feature I took note of what results the engine actually returned. Some keywords return relevant results, but it appears the fundamental way Cuil works is inferior to the likes of Google and Yahoo. For instance, a simple search on Widgets google typically leads to a diversified listing of sites all focused around the Widgets you search for. However, Cuil seems to feed multiple deep links to the same website, much more so than Google. Cuil also returns the same results on multiple pages. This appears to be widespread with all of my searches.
There is also the issue of hacked, faked, and general clutter sites listed on Cuil. www.xuxkdmf.com/skdflwldkf/akdjf-widget showing up in the first page results for widget search makes me sick. Mal ware spread would be unstoppable if google didn’t keep up with these listings. With the all to often issues such as MS08-078 it is even more important to keep these scum sites from being found.
Cuil could have been a real contender to Google, who knows they still may be down the road. My advice to Cuil, ditch the image feature because it doesn’t work and do like MS and Yahoo (copy off of Google). Filter results down to be more unique, less of the same sites.
Google Trends a useful tool
Dec 17th
Quick post today about google trends. For those of you that don’t know google offers a really useful tool that allows you to see search trend data from all the way back to 2004 (or earlier?). trends.google.com This really has a broad range of useful applications. For example, take the current economic situation. How does it compare to years past? Just an exaggeration? Lets do a search for ‘jobs’:
So based on searches, jobs are in fact a little higher in demand this year. However it is interesting to note the drastic increase in news coverage. Another very useful and obvious observation is the seasonal nature of job searches.
Another interesting search is ‘hho’. HHO is a term coined by the alternative energy community for basically splitting water into hydrogen through electrolysis and piping the dihydrogen oxgen directly into the engine. So at the peak of the gas price madness this summer, this movement to equip hho systems to cars was really gaining ground. I have to admit I have been intrigued by this idea. It appears to produce real gains in mileage and well documented on videos all over the net. The merits of HHO are for another post however. Interestingly gas prices started to inch back down in late summer. Coincidentally so did the interest in hho. What does this say to the alternative engery movement in general if gas prices remain low? As prices rise again in summer will HHO interest rise again?
Finally, I will lead into my upcoming post with the term ‘Web 2.0′. The media coined name for the next logical evolution of what the internet is and does. The term means a lot from design aspects to social networking. So as you can see the Web 2.0 searches peaked out in Q1 of 2007 and is in a steady decline. What does this mean for web 2.0. While I honestly don’t believe we are witnessing the demise of web 2.0. I think what are seeing is the movement to the next evolution of the web. Web 2.0 is here to stay I believe and the internet is permanently changed for the better because of it. What is next you ask? I honestly don’t know. I think in 2009 it will show itself.
Fast image pixel access with GDI+ and .net
Nov 18th
I have yet again hit a brick wall with regards to speed in processing dynamic images server side using System.Drawing in asp.net. As I have covered in a previous article regarding image cropping I have had difficulty in the past finding a quick way to access each individual pixel of an image. Unfortunately my algorithm was only the result of a having to deal with a slow getpixel method. Using what I had at the time that was the best I could come up with.
Enter ASP.net and a wealth of additional capability. I came across a great set of articles from bobpowell.net One great article in particular pertained to my issue exactly. Direct memory access to pixel data using lock bits. Here is a direct link. It is not often that I find exactly what I need, but this was perfect.
Here is a snippet of Bob’s code, I also added some lines to elaborate where you can access the other 3 components of the image data Bob’s code did not illustrate.
BitmapData bmd=bm.LockBits(new Rectangle(0, 0, 10, 10), System.Drawing.Imaging.ImageLockMode.ReadOnly, bm.PixelFormat); int PixelSize=4; for(int y=0; y< bmd.height; y++) { byte* row=(byte *)bmd.Scan0+(y*bmd.Stride); for(int x=0; x< bmd.width ; x++> { row[x*PixelSize]=255; //blue component row[(x*PixelSize)+1] = 255; // green component row[(x*PixelSize)+2] = 255; // red component row[(x*PixelSize)+3] = 255; // alpha component } }
So what is the advantage of this? One word SPEED. You can accomplish the same thing (reading,writing) pixel data using the managed code in system.drawing (getpixel() ), but you will find very quickly if you are doing any serious processing it is very slow. This method is far superior assuming you know the risk (you can potentially mess with memory you aren’t supposed to). I’m happy to report I have an efficient cropping function now that appears will speed up alot of code already in use.
Slow javascript performance in IE (string concatenation)
Nov 17th
I’ve come to realize while IE 7 is no less than a landslide improvement over IE 6, it is still IE. While IE alone in the market appeared to be a superior product, compared to the likes of firefox it is simply inferior. Firefox script interpreter is all around faster, in my experience it is not just 2-5x faster, it can be 100x for some operations. Crazy right? I’ve been pushing the envelope with an ajax/dojo based site I’ve spent a large amount of time on. To be blunt there is more than one occasion during the development process I have had to rewrite code to accomadate the script execution of IE 7. Looking back most of the time the script was poorly thought out set of operations that needed to be rewritten anyway.
My last road block however was a particular chunk of JSON data that was packaged up base64 encoded then sent off to the server via the dojo xhrpost method. I really was scratching my head whenever I was in IE and got up to a 3-10 second delay while sending this data to the server. While in Firefox and Safari there was none. After a period of a few hours I narrowed the delay to my base64 encoding script running on the client side causing the delay. It didn’t take long start finding that IE is incredibly inefficient as string concatenation. The solution is simple. Implement a string buffer. I have provided some snippets along with the corrected JS file for viewing.
// addresses some speed issues with IE function StringBuffer() { this.buffer = []; } StringBuffer.prototype.append = function append(string) { this.buffer.push(string); return this; }; StringBuffer.prototype.toString = function toString() { return this.buffer.join(""); }; // end buffer function encodeBase64(str){ ... var buf = new StringBuffer(); // new buffer code ... //result += (base64Chars [(( inBuffer[0] << 4 ) & 0x30) | (inBuffer[1] >> 4) ]); buf.append(base64Chars [(( inBuffer[0] << 4 ) & 0x30) | (inBuffer[1] >> 4) ]); ... }
Source for the entire base64 file here:
base64.js