While the Qosmio X500 might appear a beautiful beast on this screen,
Toshiba fails miserably at hiding the horrible effects imposed by the poor view angles here:
Ah, sad laptop world…
It’s also ironic that Toshiba prooves at the same time that they don’t have enough money/expertise to host their own video. I don’t know for you, but for me YouTube doesn’t equal hip on a web site, it equals poor independant blogger or something less-than-cool like that.
I’ve made a few tests on –videoquality encoding with Theora via ffmpeg2theora which I think is the best way to encode OGV media. Earlier tests conducted with ffmpeg2theora 0.25 reveal that 2-pass Target Bitrate encoding with Theora is less efficient than videoquality encoding, which is a one pass constant quality variable bitrate encode.
This might be surprising if you come from an H.264 encoding background, where quality-based encoders are almost nonexistent, but it’s quite the buzz with Theora. I could get the best quality encode possible on a somewhat motion-intensive animation with only 4.4 Mb/s.
Here’s the result of an intensive scene taken from an AMV that will appear in February at the G-AMV 2010 contest made by AMV-Canada. I’m the president of AMV-Canada and I do pretty much all of the grunt work of web encoding for the moment, so I was testing OGV encoding for our HTML 5 Open Video technology.
This scene is a very intensive scene which goes up to 7 Mb/s in VQ 10 . What you have to look for is discrepancies in the screenshots from VQ 9 down to VQ 0 comparatively to VQ 10. The video is a 740 x 410 pixels, which is a close approximate of what you can expect for an average SD video.
Size 99.03 MiB
Average Bitrate 4499 kb/s
Size 78.35 MiB
Average Bitrate 3589 kb/s
Size 61.41 MiB
Average Bitrate 2770 kb/s
Size 48.91 MiB
Average Bitrate 2255 kb/s
Size 39.79 MiB
Average Bitrate 1800 kb/s
Size 31.43 MiB
Average Bitrate 1415 kb/s
Size 24.52 MiB
Average Bitrate 1117 kb/s
Size 19.12 MiB
Average Bitrate 859 kb/s
Size 15.19 MiB
Average Bitrate 682 kb/s
Size 11.40 MiB
Average Bitrate 512 kb/s
Size 8.86 MiB
Average Bitrate 398 kb/s
What you can observe is that the codec, in general, doesn’t start to drop in perceptible quality until VQ 8, and it’s still very subtle. VQ 8 is ideal for high quality encoding with minimal space.
VQ 7 starts to have noticeable blocking going on which often plague Theora videos. It’s very particular and while not exactly in your face, it’s always sort of there in lower quality Theora videos. VQ 7 might be more adapted to high quality web streaming.
VQ 6 and VQ 5 on the other hand fit perfectly in what the average H.264 encode looks like in terms of bitrate. While of substantially lower quality than H.264 at the same bitrate, both choices remain watchable and ideal for the web.
From VQ 4 and down, the codec starts to lose its ability to define straight lines and makes text increasingly hard to read. VQ 1 and VQ 2 then lose any ability to define detail and text becomes unreadable in most cases.
You can also enable –optimize in ffmpeg2theora, which makes encoding slightly slower and increases quality a bit. There’s definitely less blocking, but the difference is so minimal that with side-by-side comparison it’s often hard telling which is actually better. So while this might be a must when encoding, it’s definitely not worth re-encoding your whole library for it.
However you look at it, today’s major operating systems take a lot of resources. We run high performance applications like video games that could go to such better lengths with our machines had they not have to run on top of operating systems like Windows.
If you have a modern system with 12 GB of RAM, it obviously does not really matter. Most often you will most likely find the majority of applications on your system run perfectly fine while your friend might argue with you they are too slow to work with on older computers.
However, if you have such wares as a netbook, memory usage might be something you want to have an eye out for. Having a netbook is like stepping back 5 or 6 years in computing power and the speed and efficiency of the applications you run become crucial.
For example, Windows 7 on a netbook is already the very limit of what you can run as an operating system. It will eat at least half a gigabyte of RAM and will limit your use of your netbook to applications that can fit in the rest, which is most often less than 50% of your total RAM.
However, take Chrome OS, which will most likely take substantially less memory (it’s just a browser after-all), and you’ve got a different story. Your netbook might gain as much as twice its previous memory capacity for running software.
If Google was ever to enable the development of native applications for Chrome OS, a simple thing to do because it’s Linux based, your netbook’s potential as a browser-only platform will surely change. Any long-time professional software user will tell you that although current-day pro software like Photoshop take a modern computer to run, they used to be able to use Photoshop on the older computers, which were new at that time.
Chrome OS brings the same power back to older computers and most specifically netbooks. High-performance compiled web apps destined to these very netbooks might not be so far-fetched after all.
I’m seriously happy about Opera right now. Not only have they succeeded at keeping up with the technical updates, their browser is now finally another proud owner of a native shell on Mac.
This whole native shell movement really makes my eyes happy. Afterall, we did go from 9.6 to 10.5:
From the left to the right, Opera 9.6, Opera 10.1, Opera 10.5 Pre-Alpha for Labs.
10.5 also has a nice addition, smoothly animated tabs à-la-Safari. We might see additional changes by the time this hits release, but it really makes me want to use Opera more. (Note, Opera 10.5 has other interface change niceties not covered here, but you get the gist of it; more animation and coolness, including for the first time being able to tab through checkboxes on Mac)
Opera Software proved once again that sheer technical expertise can surpass open source communities, as well Google on that note. On my computer, I got 393.2 ms for Opera 10.5 and 428.4 ms for Chrome 4 in the SunSpider JavaScript Benchmark, and it’s apparently even faster on Windows but I didn’t test that yet. Amazing.
Many thanks to Parakey for their Firebug Firefox Extension and to Opera Software for their Opera Dragonfly without which this CSS study wouldn’t have been possible.
If you’re an experienced web interface coder like me, the kind of guy who spent several years doing more than just toying around with HTML and CSS, you know that mastering these is pretty close to arcane magic. When using standards-compliant browsers, the CSS box model might not look logical. A lot of times I have faced issues where I thought the specifications were simply screwed up, but they are not. The real issue lies within the default CSS values established as standard.
It’s the real part that’s screwed up, but fortunately it’s easy to fix it and make it work the way it apparently should. The trick is to overwrite the defaults with your CSS style sheet. One marvel of specifying a higher than average amount of CSS rules is that even browsers like Internet Explorer 7 will end up displaying your web site correctly because a major problem in web standards is the default rule set. Hence, we’re essentially going to overwrite these defaults here.
Let’s start by breaking down this sample code:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>CSS Box Model Test</title>
<style type="text/css">
.div01
{
width:150px;
height:150px;
background-color:blue;
}
.div02
{
width:150px;
height:150px;
background-color:green;
}
</style>
</head>
<body>
<div class="div01"></div>
<div class="div02"></div>
</body>
</html>
This perfectly valid HTML 5 code will produce a blue and a green square like this:
What’s important to notice here is how the defaults specify a margin of 8px all around the body element. These defaults are what make HTML easy and very much helped its success. It avoids us having to specify tons of display properties. However, simplicity is always at the cost of control. Hence, designing very complex CSS layouts might result in a few headaches linked to surprise default values that weren’t expected. Unlike what we tend to think, most padding and margin values actually don’t default to 0.
To show what I mean, change the div02 to this:
<div class="div02"> <h1>H1</h1> </div>
And you get:
Take note here that we did not provide any padding or margin information to any of the squares for them to move down like this. If you see this in one of your complex designs, you might end up searching a complete afternoon for some discrepancies in your div blocks. The margin is actually on neither squares, those default to the expected 0px margin; it’s on the h1.
The problem lies in common mistakes made with the W3C Box Model, which differs quite a lot from the traditional box model older web developers might be used to. Quirksmode.org explains it very well.
Firebug can also give us insight at how the margin affects the result:
This is where it gets tricky though. The width of any text element like our h1 is predefined to fill its parent container from left to right. Our h1’s width is thus 150px. The height of any text element is predefined based on the font. In this case, it’s 36 px. This is shown by the green highlight around the h1. Our h1 also has a predefined top and bottom margin so to make it stand from the rest of the text. This is natural and removing this margin makes your text look cramped, but this margin is exactly where all the problem is.
In the W3C Box Model, there exists three ays to define extra spacing between elements; padding, borders and margins. The padding comes first, and is then followed by any border, and lastly by the margin. All of these elements exist outside the element’s width and height, meaning a 20px padding and a 100px width will equal a total width of 120px.
The border is self-explanatory, but the difference between a padding and a margin is more subtle and difficult to grasp. Layed down on paper though, it’s actually quite simple.
The margin is transparent and lies outside the border of an element. Even if the element has a border of 0px, it is still outside the border. A margin does not acquire the background color of an element.
The padding on the other hand lies between the border and the box of an element, or inside the border if you want. Hence, a lot of people like to call the padding a margin but for the an element’s content instead of the box. A padding acquires the background color of an element because it is part of the content (what’s within the border).
If we base ourself on the previously explained box model, then logically the h1 should be entirely contained within our green box, but it is not so. Why? Because the standards people screwed up. Wait, wait, you’re thinking, is this guy serious? Well yes I am, and all the evidence is there to prove it. In fact, a lot of modifications we can do to the code clearly demonstrate how every single browser manufacturer, probably due to the people who made the ACID tests, communally screwed up on this and manufactured a giant bug.
To understand how this bug works, let’s first look at what the result should look like:
To obtain the following, I replaced the 21px margin with a 21px padding like so:
h1
{
margin-top:0px;
padding-top:21px;
}
Doing so does provide a quick fix, but not in the event you’d be using a background for your h1 element. While such an occurence is rare, major web sites like Engadget use this background technique to make their links’ roll-overs. Replacing the margin with a padding would completely screw up their design by incurring a huge extra highlight on the text like so:
The real way to circumvent the problem is to use the box model in a way that doesn’t include the bug. Weirdly enough, this is quite easy and proves that it really is a bug. Simply add any padding or border to the affected box and voila, problem solved:
.div02
{
width:150px;
height:150px;
background-color:green;
padding-top:1px;
}
But just for the sake of it, I’ve made another example that demonstrates how this can only be a bug.
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>CSS Box Model Test</title>
<style type="text/css">
.div01
{
width:150px;
height:150px;
background-color:blue;
}
.div02
{
width:150px;
height:150px;
background-color:green;
color:white;
}
.div03
{
width:150px;
height:150px;
background-color:red;
}
.div04
{
width:100px;
height:100px;
background-color:yellow;
}
.div05
{
width:150px;
height:150px;
background-color:black;
}
.div06
{
width:100px;
height:100px;
background-color:yellow;
position:relative;
top:16px;
}
.div07
{
width:150px;
height:150px;
background-color:blue;
}
.div08
{
width:150px;
height:150px;
background-color:green;
color:white;
margin-top:20px;
}
.div09
{
width:300px;
height:400px;
background-color:red;
}
.div10
{
width:200px;
height:140px;
background-color:yellow;
}
</style>
</head>
<body>
<div></div>
<div>
<p>Paragraphs are also affected</p>
</div>
<div>
<div><p>This…</p></div>
</div>
<div>
<div><p style="margin-top:0px;">should technically do this.</p></div>
</div>
<div></div>
<div>Any block following another block with a margin is affected. This text doesn't have any margin.<br>
The box does.</div>
<div>
<div><p>The first block remains intact or influences the one on the previous level if it exists as it is in this scenario.</p></div>
<div><p>The second block follows the bug partern.</p></div>
</div>
</body>
</html>
Since it is possible to reproduce this bug at all times under specific conditions, it is clear this is a manufactured bug that has been hidden away as standard. If someone believes this is not a bug and that there is a logical explanation to this behavior, please post a comment and explain! (One from Håkon Wium Lie would be appreciated)
Micheal Gartenberg has had a bit of fun saying the Google Phone could be the death of Android. The rumored Google Phone is a would-be carrier-free (unlocked) phone built by HTC and sold directly through Google.
As Micheal points out: “Until someone can give me a ten-word answer to how Mountain View can manage to build an ecosystem while trying to compete with it, I will remain skeptical that the Google Phone ever comes to market”, it’s going to be hard selling that phone on the market without killing the Android ecosystem.
But as much as I’d like to believe Micheal’s great insight, my own insight says something quite different.
First of all, what ecosystem? The Android platform is just hot on paper right now. Its market share pales in comparison to the iPhone and is playing catch-up with BlackBerry. Sure, it’s quite obvious Android will be rivaling the iPhone in two years, but in two years.
Secondly, why can’t Google sell its own device? “Apple’s tried this [...] with the Newton” and failed, says Micheal. But it’s as if he was ignoring the fact that Apple did try again with the iPhone and clearly didn’t fail. The premise on which Google would kill the Android for selling a better Android phone is just plain stupid. I don’t even have to explain why it would work. Google has always worked that way; if you can’t do it as we wish, we’ll do it for you and steal your market in the process.
I’m pretty sure Google doesn’t care about Motorola, and clearly this is going to benefit the like only other major Android phone maker, HTC, because hey, they do manufacture the phone in question! Think about it, that’s HTC selling its own device without having to provide any kind of software support whatsoever. That doesn’t sound like killing a partner in my opinion, but more like giving heaven to them.
Google has long shown that the Microsoft way of thinking “don’t compete with your own market” only impedes on innovation and eventually market success. Google constantly competes with itself, making the life of everyone easier at its own cost, a very good example being the ability to use Gmail as a Pop3 client. But they don’t care, because that does only one thing: bring more people into Google and eventually give Google more money because it builds into their ultimate advertising ecosystem.
In other words, I can’t see the Google Phone as anything else than a tremendous success. And besides, the Android platform will still remain open and liked of everyone. Whether Google conquests the smart-phone market with an array of half-working crap devices from every manufacturer in the world or its own very good phone doesn’t quite make the world different; in the end, Android is taking over, and open source technologies are too at the same time, making everyone happy, except Microsoft, Apple, RIM and Nokia.
I’ve just stumbled on the Silverlight beta for Bing Maps this morning while making my daily new-feature check routine and let me tell you this makes you want to develop with Silverlight.
The experience is smooth like no other. Essentially, the Bing Maps beta replaces all the JavaScript graphics work by Silverlight. The result is an obviously tremendously faster and animated map experience. There’s even StreetView, eh, I mean SideView…
Nevertheless, the results on Bing Maps still aren’t on par with Google’s offering, and Google has a much bigger StreetView coverage. It’s nice, and I had to mention it, but I’ll keep using Google Maps as long as it’s the only Mapping Application capable of finding where I live by only typing the street name (and then again, you’d be surprised at how much it’s difficult to find a house in a major urban center with Bing Maps).
In my new career as a Java developer, as I’m French, I’ve been using the siteduzero.com’s Java tutorial. Actually, that’s just when I didn’t want to get my big Deitel and Deitel book out, but seriously, forget about SiteDuZero’s crap. I’m really sorry for the author, but as a message to you: “Your code sucks”.
All that said, if you want a serious and reliable source to learn Java, just try Java Tutorials! It’s an official publication from Sun, it’s free, and it’s more than complete (check out that massive index). You can even buy it in book form.
The only hiccup with this is the coding style. While K&R might be Java conventions, it might not be your cup of tee. I know, I’m allergic to K&R too and I prefer Allman. If you really can’t look at Sun’s code, there’s always Deitel and Deitel’s Java books.
Note: This does not cover Java EE. For that go to the Java EE 5 Tutorials (lol, it’s amazing really, they have it for like everything).
Well, after trying to find out via Google, I gave up with the stupid answers from dumb ASP.net programmers such as “VBScript is not a server-side language” or “you can’t run .asp on IIS 7″.
Sure…
So for the curious, here it is:
That’s it. IIS will now shoot the runtime errors directly into your browser window instead of saying something went wrong with the URL. I’m pretty sure this is on by default in previous IIS versions, hence the confusion.
You might also want to turn on “Enable Parent Paths” in the Behavior section, which will enable the ..\ relative path notation. Frankly I don’t know why this is turned off by default… but hey, we’re talking classic ASP here. It’s not like Microsoft really cares.
Google Chrome is out in beta for Mac and Linux. The real surprise is Linux; only heard rumors of the one for Mac.
I’ll post a review here later.