<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kevin,<br>
<br>
I spoke with a rep on Google TV, as well as a Microsoft IE rep:
neither saw an active use-case for non-square pixels.<br>
<br>
There are cases where width is stretched / squished, but they're
always handled by scaling the output image. Think of fancy window
manager effects, and of the ratio selection available on many tvs.<br>
<br>
I think the cost of supporting a scaleX and scaleY are minimal; but
as Robert suggests, the benefits are small. I've brought up the
concept of a CSS Canvas, based on Robert's comments in this thread,
where viewport transformations are taken into account by the rending
engine.<br>
<br>
<br>
<br>
-Charles<br>
<br>
<br>
On 11/23/2010 5:06 PM, Robert O'Callahan wrote:
<blockquote
cite="mid:AANLkTikQWDF3TAG2psGRFQoB9N890e=PqT0vFg5_SWV5@mail.gmail.com"
type="cite">On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:kevinmarks@gmail.com">kevinmarks@gmail.com</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Well, if we care about doing video processing with Canvas,
understanding anamorphic pixels is needed.</blockquote>
<div><br>
You mean the aspect ratio of the video source? Sure, but here
we're talking about the output device.<br>
<br>
Anyway, adding APIs to help browsers display better quality
output on NTSC or PAL TVs seems like a waste of time to me.<br>
<br>
Rob<br>
</div>
</div>
-- <br>
"Now the Bereans were of more noble character than the
Thessalonians, for they received the message with great eagerness
and examined the Scriptures every day to see if what Paul said was
true." [Acts 17:11]<br>
</blockquote>
<br>
</body>
</html>