Monthly Archives: September 2010

Facebook doesn’t confirm e-mail addresses

I don’t have a Facebook account.

If Facebook has been harassing you with messages that seemingly came from me, please take it up with them.

I should have received an e-mail when somebody registered an account under my e-mail address. Evidently, either the FAQ lies, or I threw the mail to the spam bin ages ago and forgot about it. The latter is more likely, but that does not excuse websites from applying a simple “confirm before use” policy.

Update: What makes me even angrier is that whoever registered under my e-mail address was able to see my list of potential contacts.


Chrome/Chromium with GPU acceleration

Chromium just switched on GPU acceleration. There was a changeset in the source tree a few hours ago causing some test failures, prompting me to check what interesting development was happening. Apparently they changed the command-line switch needed to enable GPU acceleration, which seems to indicate that they wanted it enabled by default. This is likely a reaction to yesterday’s Slashdot coverage on GPU acceleration in web browsers.

Image showing Chromium automated test results with more than 20 failures

The first thing I noticed when using this Chromium build was its bugginess. As in crash-your-tabs buggy. There were quite a lot of test failures caused by the change.

The other problem could only be seen in pages with HTML5 Video (and most likely Canvas as well): the text in these pages looked blurry.

Image showing blurry font rendering

Compare with normal rendering:

Image showing sharp font rendering

(Update: r59324 has been reverted, so no GPU acceleration for now.)
(Update (2010-09-18): Looks like it’s back. I haven’t noticed any particular instabilities, so that’s great. Blurry fonts I can manage; that’s also how Firefox nightly looks like, and I’m starting to suspect my graphics driver.)

At least now we know that GPU acceleration in Chromium is not ready yet. At least now I know that whatever technique these browsers use to render pages with GPU doesn’t sit well with mine (an Intel chip).

Pango: Determine if a font is monospaced

If you have a GtkFontButton, finding out whether the chosen font is monospaced is quite a complicated process. Here is a complete walk-through.

(By the way, I will be using PyGTK’s Pango documentation because the C version is a mess.)

FontButton.get_font_name returns the font family (a.k.a. “font name”), style, and size; for example, “Liberation Serif Italic 14”. The first thing we need to do is pick just the family name. We do this by going through a PangoFontDescription.

desc_str = font_button.get_font_name()  # Liberation Serif Italic 14
desc = pango.FontDescription(desc_str)
family_name = desc.get_family()  # Liberation Serif

Next, check whether the font family describes a monospaced font. Here is where it gets dodgy. We need an arbitrary PangoContext, which can be obtained from a GtkWidget using Widget.get_pango_context. We then list all available font families and find the one with the appropriate name. Call FontFamily.is_monospace to finish the job.

(By the way, this is also a good place to show off Python’s for-else construct.)

context = widget.get_pango_context()  # widget can be any GtkWidget.
for family in context.list_families():
	if family.get_name() == family_name:
else:  # Should not happen.
	assert False
family.is_monospace()  # False -- Liberation Serif is proportional.