Recently while coding a game/scene library for Canvas I had the idea of implementing pixel perfect collision by using an offscreen canvas where to draw the two objects alone and check if they collide.
This can be easilly done with the source-in/destination-in composite operation. If any pixel of the offscreen canvas if not white then the two objects collide. It seems a great idea, but I had a bad surprise when testing it on Chrome and Safari.
Indeed it seems that source-in and destination-in have been differently intended on webkit. I find the Mozilla implementation more useful, but as the Canvas 2D specifications are written it is difficult to understand what they mean by Display the source image wherever both the source image and destination image are opaque. Display transparency elsewhere
Here you can find a screenshot of the two different behaviours
It seems that one of the main problems with websites on iPad when handling with a lot of images is the limited memory reserved for images. If you have a lot of big images you will start seeing white boxes instead of your pictures when viewing the site on the iPad.
It seems somehow that Safari for iOS ignores the memory limit for background images, so you can consider substituting your img with divs with background-image to avoid hitting against the limit.
This is also valid for iOS Applications that use UIWebView.
Like every year Packt Publishing organizes the Open Source CMS Awards, right now they started the nomination phase.
The following categories make up the contest.
Open Source CMS
Hall of Fame CMS
Most Promising Open Source Project
Open Source E-Commerce Applications
Open Source Graphics Software
We decided to propose ACR for the Most Promising Open Source Project and Open Source CMS.
Even if young our CMS is already interesting since it’s quite easy to deploy, it integrates in other turbogears applications (like we did for iJamix) in a breeze and has already most of the features you would expect from a full fledged CMS.
In our humble opinion is the best and most promising Turbogears2 based CMF/CMS out there.
Can you see any reference to Ruby here?
They even have an ObjectiveC library, probably cause of the huge amount of Objective C web frameworks, but no official Ruby library.
Do they hate Ruby? Please, do not hate Ruby! I’m a poor little interpreted language used by everyone who is making real money, please love me! pleaseeeee, I’ll make you rich!
Yeah, ok, I’m sarcastic and there obviously are some unofficial Ruby libraries around there for GData.
A great part of VPS users run a CentOS, also a lot of real servers run CentOS nowadays. Usually this happens as CentOS users hope that it should be more stable, tested and secure then other distributions as being derived from an enterprise commercial one.
This might be true for most cases, but while developing PyHP we found a lot of “unknown mysterious bugs” that happened only on CentOS. After some investigation we found that apr_stat on CentOS always returns 0 as file size (this made quite interesting to allocate buffers or use mmap to read files) and also that bucket brigades had a strange behaviour, and as strange I mean that in some conditions they never considered terminated the request and caged the user in a wonderful infinite loop (as in “while(true)” not as teleporting the user to apple head quarters).
As a big percentage of PyHP users rely on CentOS we had to rewrite some parts to use lstat instead of apr_stat and also move away from bucket brigades to ap_should_client_block. If you are using CentOS and find any problem with PyHP try to upgrade to the latest svn trunk, also if you are using the svn trunk please upgrade to the latest one as there was a bug caused by the process of migrating from bucket brigades to apr_should_client_block that might prevent your users from being able to upload big files.