Improving Animation Performance for PaperVision3D objects

I am currently working on a project that requires Axiis and Flex Charts to be used on PaperVision3D objects. The end result was a very CPU-intensive component, that would perform jagged animations.

While optimizing for performance, I had to perform several steps – listing them down here in case it proves useful in the future.

  1. Ensure that the MovieMaterial (used for the side) is instantiated with animate = false (unless you really need it to get updated frequently)
  2. Set interactive = false, unless you really need interaction with the charts (or any other flash movie for that matter) on the object surface
  3. Reduce the quality of the stage when an animation is going on, then set it back to high/best.

The last one is particularly useful in improving framerates without loading the CPU. Also it has very less impact – people normally do not notice the reduced quality when the object animation is going. Once it is done, you can set it back to high.

Smoothing resized distorted images in Flex

For some strange reason, the images that are resized in flex appear pixelated (lose their sharpness) and look like low resolution pictures. Turns out there is a very simple solution to this, as highlighted by Ronald – we just need to create a smoothing function and apply it to the image.

Sake of convenience, repeating his solution here –

<!--?xml version="1.0" encoding="utf-8"?-->

<![CDATA[ //call this function from where ever you need Image Smoothing

smoothImage(evt:Event):void{
       var myBitmap:Bitmap = ((evt.target as Image).content as Bitmap);
       if (myBitmap != null) { myBitmap.smoothing = true;}
   }

]]>

<!--Usage: call complete="smoothImage(event) from image component ) -->

Why this happens in the first place, I don’t know, but this sure is a good solution.

Stop Building Useless Software

A few days back, I came across a presentation by Jeff Patton on InfoQ on how not to build useless software. I would encourage you to view the 1 hour video – well worth your time.

Jeff highlights how easy it is to start building worthless stuff – things that don’t really solve the right problems (or worse, solves the wrong ones), things that do not really produce any returns, eventually leading to poor ROI on the new features added. His main appeal was to stop focussing so much on output of the software team (meaning how much code is written how fast) and to start focussing on the outcome of the software that was written. He further says that the goal should be to reduce output as much as possible while improving Outcome.

Such a subtle but a powerful message – too often we are worried about how many features are built, that we neglect caring about how much business value has actually been created. Such a waste.

MongoDB with winforms

With NoSQL gaining a lot of momentum, I think I really ought to try it out in one of my projects. MongoDB seems to be a good choice, and Michael explains how to get going with winforms and MongoDB.

The best thing about MongoDB is that there is very little Object-Relational mapping needed since all the objects are stored as JSON documents. It should also make schema updates more painless (though for large changes some data manipulation might be required).

Joins vs Scalar-sub queries

Have you ever considered the difference between the following?

select t1.col1, t2.col2
from table1 t1 inner join
table2 t2 on t1.col3 = t2.col3

and

select t1.col1,
 (select t2.col2 from table2 t2 where t2.col3 = t1.col3)
from table1 t1

The first one is a join, whereas the second one uses something called as scalar-sub queries.

The above two will give very similar output, but the second one will be generally much slower than the first one. At least in most cases. This is because the in-line query will be run once for each row of output from the main query, and that generally proves to be much more expensive than a simple join (which accesses both the table only once).

Is there any time when the scalar sub-query works faster? Yes, sometimes distribution of data in the tables and the way indexes are designed can make the second one faster, but this rarely happens; and especially if you need multiple columns from the same table for the same condition, then scalar sub queries can be horrific .

To be ANSI or Not to be

What’s the difference between the following two queries?

SELECT *
FROM table1 t1, table2 t2
WHERE t1.col1 = t2.col2

And

SELECT *
FROM table1 t1 INNER JOIN
     table2 t2 on t1.col1 = t2.col

Well, nothing really. At least in the most popular databases.

Except that the second query is an ANSI standard and is pretty much guaranteed to work with any RDBMS that is worth its salt. The First one is the query language supported by some earlier versions of proprietary databases like Oracle and SQL server, and they continue to support them for legacy purposes, but there is no real need to write new code in that fashion.

What’s more – the ANSI syntax is much cleaner, much more precise in stating which join to use and what are the columns to be used in that join and just so much easier to write and read. It’s much harder to miss joining conditions and end up with Cartesian joins. It is much easier to modify, if you want to add or remove tables from the select query. All-in-all, there is no reason really why all new queries should not be written in the ANSI Standard format, so if you ever asked yourself that question, hope you got your answer.

JOINS

Anyone who is familiar with SQL to at least some extent will know that you can access data from multiple tables by using joins on certain columns. However there are a lot of joins out there – inner, left outer, full outer, cross. And sometimes some of these can get a little confusing – for instance where to use a left outer join vs a full outer or an inner join. And then what’s this left join. Or Natural join. Or Self Join.

For anyone who has ever been in this dilemma I recommend first reading Jeff Atwood’s post which explains the basic joins beautifully with the help of Venn diagrams.

Did you read it? No?! Go back and read it now. And then come back.

If you are done, then you must agree that he does such a wonderful job, that I don’t have to explain once again! However just to reiterate for the sake of repetitive retention,

You use –

  • an inner join when you need matching records only from both tables that you are joining
  • a left outer join when you need to get matching records from both the tables AND all the other records as well from the left table
  • a full outer join when you need to get all the records from both the tables
  • Cross join – well thats basically just to get all combinations of all records in both tables, there is no ‘joining condition’ as such. Very rarely used in real-life applications. For two tables with m and n records each, the cross join will return m*n records.

There is also a right outer join – similar to left outer join, but all the records of the table to the right are returned instead of the left one. However this is rarely used, since it can always be replaced by a left outer join by just changing the sequence of tables. Also it is sometimes difficult to evaluate the result of a right outer join (compared to a left outer join) when it is part of a larger multi-join query.

Note: Left outer join and Right outer join are also called Left and Right joins respectively. Outer is just a better way of communicating the intent of the join.

There are other joins like self-joins or natural join, however it is always best to think of these as special cases of inner joins and even write the SQL as such. (Natural join for instance automatically determines which column the join is based on, but it is a better practice to mention it explicitly anyways).

SQL – the horror

Yes, SQL is a horror, especially when not done right. It is really easy to let queries go out of hand, and just write lines and lines of code just to craft a single SQL query. You cannot debug them. You cannot easily maintain them. You cannot easily tune them. Then why do people write them in the first place?

To the other end of the spectrum are people who completely avoid writing queries that access more than one table at a time. These are the guys leaning towards no-sql, non-rdbms solutions, developers who prefer to do the joins in their application code instead of writing a few lines of sql. ‘That’s right, we don’t need no stinkin’ SQL!’

That’s why I decided to start this blog, to get people appreciate the art of query writing once once more. Hopefully, I can manage to convince a few of you at least, to dabble into writing beautiful sql queries again.