Programming tidbits

Monday, August 8, 2011

Clamping short to unsigned char

Here is a standard video processing problems. Your 8-bit pixel values are typically in the range 0-255. If you do some processing on them which lead their values of this range you need to bring them down to this range. Negative values are clamped to 0 while positive values greater than 255 are clamped to 255.

A typical unoptimized implementation looks like follows.

  1: unsigned char clamp(short value){
  2:   if (value < 0) return 0;
  3:   if (value > 0xff) return 0xff;
  4:   return value;
  5: }

After long time, today I ended up seeing a much nicer implementation in FFmpeg code base which basically looks like:.

  1: const unsigned char clamp(int a)
  2: {
  3:   if (a&(~0xFF)) return (-a)>>31;
  4:   else return a;
  5: }

And I think, with a single if statement, its wonderful!

Sunday, August 7, 2011

A do while in a Macro

Looks like I know very little of C. So I never thought I would ever need to use a do while loop in a Macro.

Now consider this. A typical swap function looks like following:

  1: template void swap(T& a, T& b){
  2:   T tmp;
  3:   tmp = a;
  4:   a = b;
  5:   b = a;
  6: }

As you can see that there are three different things on which the function depends, the type T and the variables a and b. How can I write a C Macro which does exactly the same thing?

  1: #define FFSWAP(T,a,b) do{T SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)

This is taken liberally from common.h in FFmpeg source code.

So we are writing a do,while loop which runs exactly once. Inside the loop we have a temporary variable created of type T (we choose a name for the temporary variable which is not expected to be taken by other variables inside the function). And rest is essentially the same 3 statements to achieve swapping.I still don't fully understand why did we need to add the do/while with this Macro. It might work without do/while also.

Please note that I don't want to say that macros are better than function templates. I just want to say that, I never knew about this macro magic.

Functional programming and GCC

I was surprised to find that its possible in GCC to specify whether a function is pure or not at compile time. A pure function is a function which has no side effects. i.e. Its output depends solely on its input arguments and it doesn't affect any other resource in the system.

GCC allows one to specify function attributes. There is a specific attribute "pure" to specify pure function. E.g.: Publish Post

int square (int) __attribute__ ((pure));

Essentially this helps in doing specific compiler optimization (common sub-expression elimination). E.g. If a piece of code calls square(2)*square(2), compiler can rewrite it in such a way that square(2) is called once and the computed value is reused in place of second call to square(2).

Functions like strlen and memcpy are very good examples of pure functions. While flose(), feof() [in a multi-threading environment], a function which may lead to an infinite loop are all examples of non-pure functions.

This is covered in detail at Function Attributes in GCC.

Wednesday, June 8, 2011

Google Chrome Layout Bug

It seems that the em calculations in Google chrome are slightly off track. Following is a small piece of HTML using DOJO toolkit’s default CSS. Its font size and line height calculations are based on http://24ways.org/2006/compose-to-a-vertical-rhythm

  1: <!DOCTYPE html>
  2: <html>
  3:   <head>
  4:   <style>
  5:   @import url("http://ajax.googleapis.com/ajax/libs/dojo/1.6/dojo/resources/dojo.css");
  6:   </style>
  7:   </head>
  8:   <body>
  9: <blockquote>
 10: Testing dojo blockquote.
 11: </blockquote>
 12:   </body>
 13: </html>

The relevant CSS is presented below:

  1: body { 
  2:   font: 12px Myriad,Helvetica,Tahoma,Arial,clean,sans-serif; 
  3:   *font-size: 75%;
  4: }
  5: 
  6: 
  7: blockquote { 
  8:   font-size: 0.916em; 
  9:   margin-top: 3.272em; 
 10:   margin-bottom: 3.272em; 
 11:   line-height: 1.636em; 
 12:   padding: 1.636em; 
 13:   border-top: 1px solid #ccc; 
 14:   border-bottom: 1px solid #ccc;
 15: }
 16: 
 17:

Now if we look at this block-quote’s layout in Firefox (4), it looks like as follows:

While the layout in Google Chrome (11.0) looks like:

You can notice that Firefox reports the padding to be 18 pixels, while Chrome reports it to be 17 pixels. Similarly, Firefox says the margin to be 36 pixels while Chrome considers it to be 35 pixels.

I think at least one of them is wrong.

Looking at the stylesheet, the computation goes like this:

font-size = 12 * 0.916 = 10.992 pixels

padding = line-height = font-size * 1.636 = 17.983 pixels

margin-top = margin-bottom = font-size * 3.272 = 35.965 pixels

Looking at computed styles, we can notice that for both Firefox and Chrome, the font-size is coming out to be 11pixels. It looks like Chrome is truncating margins and padding while it is rounding the font size.

Monday, June 6, 2011

Browser-Specific Styles with the Dojo Toolkit

I was fascinated to learn how dojo.uacss.js adds browser specific CSS classes to html element which make writing maintainable CSS straightforward by providing simple ways to write browser specific CSS customizations.