Month: February 2009

Percentage rounding and sub pixel perfection

Posted by Robert Gentel – February 22, 2009

I have been working on a grid design framework for able2know, and have been wrestling with the inconsistencies between browsers when it comes to percentage rounding. There are good static grid CSS frameworks out there (e.g. Blueprint, 960gs) but the attempts to convert them into liquid grids (e.g. Liquid Blueprint, fluid960gs) share the same bugs I was running into, where width is not correctly calculated and in IE6 and IE7 the effect was often dramatic, with columns jumping around when the browser is resized. At some widths everything would be perfect, but at others columns would wrap into the next row, breaking the layout. A couple of pixels off might not sound like much, but have a look at this video to see the effect on the layout those few pixels can have.

I set out to fix this problem, and began writing my own grid CSS framework, trying all sorts of different mathematical approaches to the problem (I was working with three columns so my initial suspicion was that the browsers were having a hard time dealing with fractions like 1/3). I also tried every IE CSS hack to try to coax the floats the grid uses into compliance, but no dice. So after more investigation, I learned that this is a rendering problem with no perfect solution for the browser manufacturs. The limitation is your monitor.

To make a very long story short, your monitor needs your browser to display objects sized in pixels. Browsers have no easy way around this problem, and there is no perfect solution. This, of course, doesn’t mean that the various browsers will find a consistent way to handle it, and as per usual IE managed to settle on the least optimal approach of the bunch.

First of all, let’s explain the problem. Let’s say you want to divide your layout into 4 columns. The pixels this area will represent may not be divisible by four. Let’s say you are dividing 50 pixels (no matter what you choose, the browser may end up with an indivisible problem, so I’m just using an easy example that John Resig used in his comparison of how each browser handles the rounding), each column should be 12.5 pixels wide according to your CSS telling the browser to divide the 50 pixels into 25% columns. The problem is that your browser can’t do this, and needs to round to an integer. No matter what your browser does at this point, there will be imperfections. If your browser rounds down there may be gaps and if you round up, then there can be an overflow.

Here is a test you can use to see this error in effect in your browser. It should display a black box, but drag your browser around resizing it, and at some sizes you should see gaps (in Firefox 3 you may not be able to do so due to an innovative way they are handling the rounding rounding the layout to 1/60th of a CSS pixel).

Now I understand the limitations each browser faces, and how they can’t possibly get it all perfect, but what IE does that breaks layouts as you resize the browser, causing your divs to jump around is round up. By rounding up they may cause your columns to exceed the width of their container, and wrap. There’s not a great way around this, and the only easy solution is to not let your columns add up to 100%, leaving room for rounding up without breaking your layout. It’s not a great solution, and it ruins the pixel perfect grid I was trying to implement on able2know with more space on the right than on the left but I thought I’d write up the problem in case others need it to fix their floats.

Other sources:

https://bugzilla.mozilla.org/show_bug.cgi?id=177805

https://bugzilla.mozilla.org/show_bug.cgi?id=63336

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=334118

http://www.satzansatz.de/cssd/geckogaps.html

http://www.ojctech.com/content/css-jumping-columns-and-ies-percentage-rounding-algorithm

Nested Grids in YUI Grids CSS

Posted by Nick Ashley – February 17, 2009

Today I was trying to achieve a 25%|50%|25% layout within the main block of my YUI Grid CSS layout. Everything I read in documentation seemed to indicate you could nest grids in any way you desire. So I tried doing the following:


    <div class="yui-gf">
      <div class="yui-u first">
        <p>First Column (25%)</p>
      </div>
      <div class="yui-u">
        <div class="yui-gc">
          <div class="yui-u first">
            <p>2nd Column (50%)</p>
          </div>
          <div class="yui-u">
            <p>3rd Column (25%)</p>
          </div>
        </div>
      </div>
    </div>

However this didn’t work, it appears you can only nest grids in the ‘first’ column, unless you are using ‘yui-g’ (instead of one of the alternate layouts, such as yui-gc above). I couldn’t find this documented anywhere, but I don’t know why else the above code wouldn’t work.

I asked for help on twitter, and senior Yahoo engineer and CSS component author Nate Koechley (@natekoechley) was kind enough to point me to this solution. It appears that moving the nested grid under the ‘first’ unit fixes the problem. Of course, then you have to change which grids you are using, as follows:


<div class="yui-ge">
  <div class="yui-u first">
    <div class="yui-gd">
      <div class="yui-u first">
        <p>First Column (25%)</p>
      </div>
      <div class="yui-u">
        <p>2nd Column (50%)</p>
      </div>
    </div>
  </div>
  <div class="yui-u">
    <p>3rd Column (25%)</p>
  </div>
</div>

This seems to reinforce my hypothesis that nesting of alternate grid layouts can only be done under the first grid unit. Is this by design, or is it a bug? If anyone has any insight, please let me know in the comments.

Working off the above code, I decided I might as well clean it up a little bit. Nate Koechley himself says that if you are going to use a nested grid, you do not need to enclose that grid in a grid unit div (in other words, a grid container can act as a grid unit). This was said during his YUI CSS Foundation speech (about 24 minutes in).

However, I quickly found that removing the first grid unit div broke the layout. As this goes against what Nate has said publicly, I am curious if this is a bug or if he misspoke in his presentation. Here is the non-working code:


<div class="yui-ge">
  <div class="yui-gd first">
    <div class="yui-u first">
      <p>First Column (25%)</p>
    </div>
    <div class="yui-u">
      <p>2nd Column (50%)</p>
    </div>
  </div>
  <div class="yui-u">
    <p>3rd Column (25%)</p>
  </div>
</div>

I would like to point out that I am loving the idea of the YUI Grid CSS, and am hoping to utilize it in all my future projects. All of the issues I have discovered thus far are not deal breakers. I am simply looking to master the framework in a basic testing environment, so I’m not wresting with it in a complex, large scale implementation. So again, if anyone has any insight, I would be happy to hear it!

What is the best PHP accelerator to use?

Posted by Robert Gentel – February 1, 2009

Well let me go ahead and tell you. Of course, this is all just my opinion and your milage may vary.

First, I will discuss the role of PHP accelerators (Opcode cache) in server tuning and scalability briefly. These tools will not enable your server to handle much more traffic in most scenarios. In some, the additional overhead of the PHP caching will even cause more load, others gain a marginal improvement by getting requests served a bit more quickly and having fewer concurrent connections. But they will not significantly raise your concurrent user limitations, as in a LAMP stack your bottleneck is usually at the database.

The way these PHP accelerators work is by caching the compiled bytecode of your human-readable PHP. Normally, your PHP code is compiled and then executed at runtime but these tools cache the compiled code, saving the expense of compiling it and thusly generally save you a bit of CPU at the cost of some increased memory usage.

So what PHP acceleration can do is make your PHP execute more quickly, and execute in roughly half the time. But it’s important to understand just what it’s accelerating, because your PHP execution is typically not what most influences the perception of speed to the user. To the user it’s a combination of page generation time, network latency, and page rendering time. These php caching tools may influence the page generation time but as I’ve already said, the database is usually the key there, and it’s both the bottleneck for concurrent users as well as the bulk of the page generation in typical setups. To make the biggest difference there you need good database design and data object caching with something like memcached, but here we’ll go over the options to improve your PHP execution times.

Alternative PHP Cache – http://pecl.php.net/package/APC

eAccelerator – http://eaccelerator.net/

XCache – http://xcache.lighttpd.net/

Zend Platform – http://www.zend.com/products/platform

ionCube PHP Accelerator – http://www.php-accelerator.co.uk/

Turck MMCache – http://turck-mmcache.sourceforge.net/index_old.html

On the able2know Q&A site we have used Zend and Turck MMCache in the past, with favorable results, but I am on a scalability and performance crusade here, and wanted to pick out the best of the current crop. Turck MMCache has not been actively developed for a while now, and is not a viable option for us to use in production, so that one’s out. I did the research into a variety of benchmarks (see chart), and with few exceptions the main competitors perform close enough to each other to make the performance differences less of a deal-killer in a selection between them. Simply put, the marginal performance gains you may acheive by selecting one over the other may be outweighted by differences in things like price, or how actively the code is being developed.

So I narrowed the selection down to XCache, APC and Zend. Zend does much more than PHP caching, and may be the right choice for others but they are a proprietary option that you must pay for, and that doesn’t justify the cost difference through performance gain as a PHP accelerator. XCache and APC are developed by well known programmers in the open source world, being the developers of lighttpd and PHP itself respectively. But between the two I am opting to use APC on able2know, as it is a pecl extension maintained by the maintainers of PHP itself (including the creator of PHP) and is reportedly going to become a core part of PHP 6.

So at least for me:

The best PHP accelerator to use is APC.