subject:"\[whatwg\] Processing the zoom level \- MS extensions to window.screen"


On 11/21/2010 4:12 PM, Robert O'Callahan wrote:
On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard ch...@jumis.com 
mailto:ch...@jumis.com wrote:


Rob: Mobile deployments using dpiPixelRatio (as has been adopted
by Moz and Webkit) and target-DpiDensity work well on the mobile,
they are not hooked to zoom on the desktop,


It is in Firefox.

I just tested in 4b7, and it's not changing dpiPixelRatio.

I'm still at a loss on why exposing additional metrics in window.screen 
is distasteful.

You currently expose availWidth/availHeight, etc.

I'm not saying this to discount your proposals, or distract from 
dpiPixelRatio as a viable option.


Why is exposing more properties to window.screen is a non-starter?

MS has already opened it up; webkit devs may have some opinions on it, 
and I'll let you know when I hear them.


http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx 
http://msdn.microsoft.com/en-us/library/ms535868%28VS.85%29.aspx


I agree it may not be a 20-year solution, but it could certainly work 
for this generation of browsers.
It doesn't *need* to be a Canvas-use case.  As I've stated, it could 
apply just as well to images.


-Charles

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-24 Thread Robert O'Callahan

On Wed, Nov 24, 2010 at 10:14 PM, Charles Pritchard ch...@jumis.com wrote:

  window.dpiPixelRatio does not change.

 Is it mozDpiPixelRatio ?


There is no such property.

Rob
-- 
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]

Re: [whatwg] Processing the zoom level - MS extensions to window.screen


On 11/24/2010 1:12 AM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard ch...@jumis.com 
mailto:ch...@jumis.com wrote:


On 11/21/2010 4:12 PM, Robert O'Callahan wrote:

On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard
ch...@jumis.com mailto:ch...@jumis.com wrote:

Rob: Mobile deployments using dpiPixelRatio (as has been
adopted by Moz and Webkit) and target-DpiDensity work well on
the mobile, they are not hooked to zoom on the desktop,


It is in Firefox.

I just tested in 4b7, and it's not changing dpiPixelRatio.


Try this:
style
div { display:none; }
@media screen and (min--moz-device-pixel-ratio: 1.5) {
  .in { display:block; }
}
@media screen and (max--moz-device-pixel-ratio: 0.) {
  .out { display:block; }
}
/style
div class=inZoomed in by a factor of at least 1.5/div
div class=outZoomed out by a factor of at least 1.5/div

Try zooming in a lot and zooming out a lot. It works for me.


While we're at it, can we get some agreement on that CSS selector? I 
can't speak for MS, but otherwise, it's a de facto standard.


That css selector is paired with the window.dpiPixelRatio variable per 
the webkit proposal.

Re: [whatwg] Processing the zoom level - MS extensions to window.screen


Sorry about that, devicePixelRatio

On 11/24/2010 1:14 AM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 10:14 PM, Charles Pritchard ch...@jumis.com 
mailto:ch...@jumis.com wrote:


window.dpiPixelRatio does not change.

Is it mozDpiPixelRatio ?


There is no such property.

Rob
--
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]

Re: [whatwg] Processing the zoom level - MS extensions to window.screen


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

Come on Robert:

It needs to be chrome-only because I don't want Web authors to have 
easy access
to information about screen pixels. They'll try to defeat our zooming or 
size

things to screen pixels, which we don't want.

They defeat your zooming by hooking into the mouse wheel and keyboard 
events.


If someone has decided to upset their user base by poorly implementing 
their scripting hooks,

that's something that they and their users will suffer.

It's not your call. You've made it your call and it's really hurting us 
over here.


Be nicer to us folks with poor eyesight. Don't punish us because of the 
possibility of coders

creating bad websites.

The past dozen e-mails all circle back to one topic: You do not want to 
expose the data,

because you don't want it to be used. I can't win that one.

I can only remark that it's a very unfortunate decision.

-Charles

On 11/24/2010 1:14 AM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 10:14 PM, Charles Pritchard ch...@jumis.com 
mailto:ch...@jumis.com wrote:


window.dpiPixelRatio does not change.

Is it mozDpiPixelRatio ?


There is no such property.

Rob
--
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]

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-24 Thread Henri Sivonen

Charles Pritchard wrote:
TV use-cases seem like they'll become more prevalent, with Apple and Google
and their devices.

Apple TV doesn't have legacy connectors--only HDMI. A quick look at the specs
of Google TV devices suggests that Google TV devices are also HDMI-only.

The devices sold as TVs these days have square pixels and are driven like the
devices sold as computer displays.

I think it makes no sense to assume that:
1) People who want to use the Web on a device positioned as a TV want to do
it using their legacy standard def TV that only has legacy inputs.
AND
2) Hardware browser vendors want to optimize APIs for legacy TVs with legacy
inputs.
AND
3) Web authors will obtain test systems that run a new browser optimized for a
legacy TV together with an actual legacy TV and will carefully optimize their
code for this case.

So I think exposing non-square pixels to Web content would be folly. It's
useless to expose variable device characteristics to Web authors unless the
characteristics vary so obviously from day one that even clueless authors are
forced to realize that characteristics vary. See
http://blogs.msdn.com/b/iemobile/archive/2010/11/22/the-ie-mobile-viewport-on-windows-phone-7.aspx

- -

I actually often run an up-to-date Web browser (Firefox trunk) using a device
sold as a TV as the display, so I do appreciate the concern that canvas
zooms badly. The easiest way to browse the Web (as it exists in reality) on a
TV is to apply a zoom factor of 1.85 to CSS pixels. (The Web as it exists in
reality is designed to work in a full-screen browser window on a
1024-pixel-wide screen and TVs are 1920 pixels wide.) I often wish that sites
used SVG instead of canvas so that they'd Just Work without resampling
artifacts with 1.85 zoom.

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-24 Thread Boris Zbarsky


On 11/24/10 4:13 AM, Charles Pritchard wrote:

 And, these aren't great lengths. It's about 6 lines of javascript.

Uh... That depends on how your drawing path is set up. If I understand
correctly what you're doing, you have to get the DPI ration (call it N),
change the canvas width/height by a factor of N, and change all
coordinates in all your drawing calls by a factor of N, right?


You're correct, I grab DPI, lets call it xN and yN, I change the canvas
width height.
Then I run .scale(xN, xY) before my drawing calls. They're completely
agnostic
to the change.


Ah, I see.  I assumed you were actually trying to draw the fonts at the 
right size for the viewer, see, as opposed to doing an image upscale of 
text rendered at a smaller size.


Try this simple testcase:

body
  canvas id=x width=500 height=500
  style=border: 1px solid red/canvas
  script
var c = document.getElementById(x).getContext(2d);
c.fillStyle = green
c.font = 30px sans-serif;
c.fillText(aaa, 100, 100);
c.font = 10px sans-serif;
c.scale(3, 3);
c.fillText(aaa, 100, 100);
  /script
/body

Note that the two strings look different in at least Firefox, Chrome and 
Opera on Mac (in fact in Opera on Mac the upscaled one looks really 
crappy, but there are differences in the other browsers too)



I'm going to go back to the ad-hominem.


shrug.  I think I'm done with this thread.


My faith in canvas coders is closer to 0.2 (on a 0-1 scale), largely
because it's not quite as mainstream yet, so only the more competent
folks are doing it.

I hope you have more respect for other parts of your user base.


What does this have to do with respect?  Canvas coders are just trying 
to get something done, as are browser users.


Browser users tend to not be experts on browser stuff.  Neither do 
canvas coders, for the most part (largely because no one is in a 
position to really be an expert on all the various parts of a browser at 
this point).  I certainly don't claim to be one.


But the upshot is that people make mistakes.  If you don't assume they 
will, you come to grief.


-Boris

Re: [whatwg] Processing the zoom level - MS extensions to window.screen


On 11/24/2010 10:23 AM, Boris Zbarsky wrote:

On 11/24/10 4:13 AM, Charles Pritchard wrote:

 And, these aren't great lengths. It's about 6 lines of javascript.

Uh... That depends on how your drawing path is set up. If I understand
correctly what you're doing, you have to get the DPI ration (call it 
N),

change the canvas width/height by a factor of N, and change all
coordinates in all your drawing calls by a factor of N, right?


You're correct, I grab DPI, lets call it xN and yN, I change the canvas
width height.
Then I run .scale(xN, xY) before my drawing calls. They're completely
agnostic
to the change.


Ah, I see.  I assumed you were actually trying to draw the fonts at 
the right size for the viewer, see, as opposed to doing an image 
upscale of text rendered at a smaller size.
You're right, font sizes do need to be managed separately in most 
implementations

as scale does not apply to the font size.


My faith in canvas coders is closer to 0.2 (on a 0-1 scale), largely
because it's not quite as mainstream yet, so only the more competent
folks are doing it.

I hope you have more respect for other parts of your user base.


What does this have to do with respect?  Canvas coders are just trying 
to get something done, as are browser users.


Browser users tend to not be experts on browser stuff.  Neither do 
canvas coders, for the most part (largely because no one is in a 
position to really be an expert on all the various parts of a browser 
at this point).  I certainly don't claim to be one.


But the upshot is that people make mistakes.  If you don't assume they 
will, you come to grief.
Assuming they'll make mistakes is different than having zero faith in 
their competence.

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-24 Thread Boris Zbarsky


On 11/24/10 1:26 PM, Charles Pritchard wrote:

But the upshot is that people make mistakes. If you don't assume they
will, you come to grief.

Assuming they'll make mistakes is different than having zero faith in
their competence.


I have zero faith in across-the-board competence.

That is, given a possible mistake it _will_ be made.  By a lot of people 
(though possibly a small fraction of the total number of people 
involved).  If the mistake is subtle, it'll be made by a large fraction 
of people.


The majority won't make any given mistake unless the situation is really 
egregious.


A fairly small minority of web authors making a mistake still translates 
to tens of millions of users or more being affected by it.


-Boris

Re: [whatwg] Processing the zoom level - MS extensions to window.screen


On 11/24/2010 10:56 AM, Boris Zbarsky wrote:

On 11/24/10 1:26 PM, Charles Pritchard wrote:

But the upshot is that people make mistakes. If you don't assume they
will, you come to grief.

Assuming they'll make mistakes is different than having zero faith in
their competence.


I have zero faith in across-the-board competence.

That is, given a possible mistake it _will_ be made.  By a lot of 
people (though possibly a small fraction of the total number of people 
involved).  If the mistake is subtle, it'll be made by a large 
fraction of people.


The majority won't make any given mistake unless the situation is 
really egregious.


A fairly small minority of web authors making a mistake still 
translates to tens of millions of users or more being affected by it.


I agree thousands of web authors do reach millions of users. Unlike 
window.open/pop up exploits, they won't DOS other sites/the browser.
I understand your decisions have an impact on hundreds of millions of people.

Politically, I'm more of a free market, free speech person than a centralized 
authority, safety over insecurity administrator.

The minority of people making mistakes will find that of the millions their 
mistakes harm, some will rise up to confront the issue.

My passion in engaging the whatwg mailing list stems from the concept that code 
is a form of speech: my ability to present a web app to users is an extension 
of personal expression. This is why I went head to head with Ian about the use 
case of rich text editing: language processes should not be limited to standard 
scripts and dialects.

I greatly appreciate the value of standards, but I am at the same time, very 
sensitive to the effects that centrally planned restrictions have on groups. 
The aggregate effect is one where tens of millions are harmed by the decisions 
of a few people in authority. I'd rather see the masses harmed by themselves 
than by authority.

I'm a fan of both Hayek and Keynes. I believe in the availability of 
information and choice, as well as the importance of leadership and structure.

In this instance, I agree that zoom is UA level and should be restricted on 
setting properties, to the UA and privileged extensions. I also believe that 
the information about zoom should be accessible, so the market may use it, so 
that emergent properties develop.

I've only asked that information be made available. The response from your group seems to 
be you can't handle the truth!


-Charles

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-24 Thread Felix Miata


On 2010/11/24 18:38 (GMT-0800) Charles Pritchard composed:


I've only asked that information be made available. The response from your group seems to 
be you can't handle the truth!


As a non-UA developer spectating since the beginning of this thread, my take 
on what you're asking for is it would be something destined to be misused to 
possibly the same widespread degree that happened when web stylists 
discovered that the CSS spec writers had given them the irrelevantly relative 
px unit. Before CSS, web designers were unable to make text more than two 
sizes smaller than the web user's default, which when they went that far, 
which was more often than not, left contextual sizing all but non-existent. 
With CSS, authors could not only make text even smaller, but could completely 
disregard user defaults, eliminating all relativity between defaults and 
results. I see what you're asking for as yet another back door to turning a 
user agent into an author agent, giving authors even more undeserved power to 
vex users, and think those responding to you feel similarly.

--
The wise are known for their understanding, and pleasant
words are persuasive. Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-24 Thread Aryeh Gregor

On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchard ch...@jumis.com wrote:
 I greatly appreciate the value of standards, but I am at the same time, very
 sensitive to the effects that centrally planned restrictions have on groups.
 The aggregate effect is one where tens of millions are harmed by the
 decisions of a few people in authority. I'd rather see the masses harmed by
 themselves than by authority.

There are two masses here: authors and users.  You advocate giving
total control to authors, but that comes at the expense of taking
control away from users.  The web platform is designed to favor users'
needs over authors' needs.  Websites are all forced to have a lot in
common: you can zoom the same way, copy and paste the same way,
navigate the same way, and so on.  This is part of why the web
platform is better for users than, say, Java applets -- it does *not*
give authors total control.

So in fact, one of the many little things that makes the web platform
nice is how users can zoom easily.  For a small percentage of users,
this is essential.  A typical author has few users and will get no
complaints if they mess up zooming, but a browser has tens of millions
to billions of users and will definitely get complaints if the browser
adds a feature that lets even one percent of sites mess up zooming.
It's then up to the few browsers to fix the problem, because you'll
never get millions of authors to all do it.  How will the browsers fix
the problem?  Probably by making the feature useless, like by making
it do nothing or return false values.  Then you're better off having
never added the feature in the first place.

That's the point of the concern over author misuse.  If authors misuse
a feature enough to affect even a small percentage of users, browsers
will compete to fix it if possible.  Consider pop-up ads -- browsers
now all block those, taking control away from authors for the benefit
of users.  Or consider the px unit, which in practice doesn't
necessarily have anything to do with pixels anymore.  We don't want to
add a feature to the platform if it will have to just be disabled when
a significant number of authors use it.  (Whether this is the case for
some *particular* feature, like exposing zoom info, is of course a
separate question.)

Re: [whatwg] Processing the zoom level - MS extensions to window.screen


On 11/24/2010 2:45 PM, Aryeh Gregor wrote:

On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchardch...@jumis.com  wrote:

I greatly appreciate the value of standards, but I am at the same time, very
sensitive to the effects that centrally planned restrictions have on groups.
The aggregate effect is one where tens of millions are harmed by the
decisions of a few people in authority. I'd rather see the masses harmed by
themselves than by authority.

There are two masses here: authors and users.  You advocate giving
total control to authors, but that comes at the expense of taking
control away from users.  The web platform is designed to favor users'
needs over authors' needs.  Websites are all forced to have a lot in
common: you can zoom the same way, copy and paste the same way,
navigate the same way, and so on.  This is part of why the web
platform is better for users than, say, Java applets -- it does *not*
give authors total control.
I've not advocated an all-or-nothing approach, and I continue to stand 
my groun dthere.


I'm advocating allowing authors to access two vital bits of information, 
which could
pragmatically be exposed with a minimum of programming hours on the part 
of browser vendors.


You can't zoom in the same way.  innerWidth and innerHeight are 
properties that an author can choose to use or not use.


I understand working abstractions, concepts... and making generalizations.

I've not advocated allowing an untrusted script to set the zoom level 
nor over-ride the

zoom controls which are completely outside of the DOM and window frame.

The web platform is better for users than Java because it's more open. 
There is no definite web platform,
there are collection of standards, and a growing consensus about which 
standards are vital to implementation.



So in fact, one of the many little things that makes the web platform
nice is how users can zoom easily.  For a small percentage of users,
this is essential.  A typical author has few users and will get no
complaints if they mess up zooming, but a browser has tens of millions
to billions of users and will definitely get complaints if the browser
adds a feature that lets even one percent of sites mess up zooming.
It's then up to the few browsers to fix the problem, because you'll
never get millions of authors to all do it.  How will the browsers fix
the problem?  Probably by making the feature useless, like by making
it do nothing or return false values.  Then you're better off having
never added the feature in the first place.

Lets?

First, the feature is being made available by other browser vendors.
Second, Lets?... If the browser lets a site crash the window, pop up 
multiple tabs, or otherwise cause a DOS, that's a big issue.


But it is not the UAs responsibility to make sure that a middle school 
student uses img alt= tags correctly.


Lets keep on the topic at hand: exposing a minimum amount of data for 
authors

who want to use that data.

There is no existing evidence that masses of programmers reading the 
Documentation on how
to use screen metrics will make mistakes in any substantial number. It's 
pure conjecture.


There are existing use cases, of using the data correctly, and of the 
data being exposed intentionally.


There are also existing cases of zoom being mishandled, through the 
misapplication of innerWidth and innerHeight.


So if we can get off the generalizations, and simply look at the merits 
of the concept,

we can move onto looking at the merits of existing proposals and practices.

Until then, we're stuck in arguments which have very little to do with 
the technical data at hand.



That's the point of the concern over author misuse.  If authors misuse
a feature enough to affect even a small percentage of users, browsers
will compete to fix it if possible.  Consider pop-up ads -- browsers
now all block those, taking control away from authors for the benefit
of users.  Or consider the px unit, which in practice doesn't
necessarily have anything to do with pixels anymore.  We don't want to
add a feature to the platform if it will have to just be disabled when
a significant number of authors use it.  (Whether this is the case for
some *particular* feature, like exposing zoom info, is of course a
separate question.)

We're considering the second item. Right now.

And man am I happy with vendors realizing that denial of service IS 
their responsibility.


If mozilla wants to add a permissions setting to say Reset stylesheets, 
don't allow access to zoom info,
or otherwise don't run ads, etc etc, that's fantastic. That's a great 
place to have competition.


There's no reasonable case for blocking those of us with mature and 
experienced judgment, from accessing data which
would otherwise be visible, if it weren't for all those  new 
programmers who might set themselves aflame.


At present, I have not seen an actual argument based on evidence here. 
We're using prior examples
and trying to draw analogies. I'm

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-23 Thread Kevin Marks

Most video displays have non-square pixels. Standard definition video
processing resolutions are 720 by 480 for NTSC and 720 by 576 for PAL though
both are 4 by 3 aspect ratio.
You can argue whether tv standards count as modern, but there are a lot out
there.

On 21 Nov 2010 16:56, Robert Oapos;Callahan rob...@ocallahan.org wrote:

On Mon, Nov 22, 2010 at 1:40 PM, Charles Pritchard ch...@jumis.com wrote:


 I would point out that the MS proposal has an independent X and Y scaling
mechanism.

Does anyone know of any modern displays which have different X and Y
resolution?




 I believe that dpi ratio is simply set to 2 (or .5... sorry a bit rusty)
on the iOS 4 retina ...
There will be cases where zooming doesn't change device-pixel-ratio. Mobile
browsers tend to have a fast zoom out which doesn't change the layout
(mostly), and that might not change device-pixel-ratio. I think that's OK
for your use cases as long as device-pixel-ratio reports the ratio as if the
page is zoomed in.



Rob
-- 
Now the Bereans were of more noble character than the Thessalonians, for
they received th...

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-23 Thread Robert O'Callahan

On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks kevinma...@gmail.com wrote:

 Well, if we care about doing video processing with Canvas, understanding
 anamorphic pixels is needed.


You mean the aspect ratio of the video source? Sure, but here we're talking
about the output device.

Anyway, adding APIs to help browsers display better quality output on NTSC
or PAL TVs seems like a waste of time to me.

Rob
-- 
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]

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-23 Thread Charles Pritchard


On 11/23/10 5:06 PM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks kevinma...@gmail.com 
mailto:kevinma...@gmail.com wrote:


Well, if we care about doing video processing with Canvas,
understanding anamorphic pixels is needed.


You mean the aspect ratio of the video source? Sure, but here we're 
talking about the output device.


Anyway, adding APIs to help browsers display better quality output on 
NTSC or PAL TVs seems like a waste of time to me.
TV use-cases seem like they'll become more prevalent, with Apple and 
Google and their devices.


I could imagine that some window managers might introduce strange 
pixel-bending effects; but that's just imagination.

I don't think we can speculate that much on output devices of the future...

In any case, I think we're just talking about limiting the scope of 
support to exposing an X and Y ratio, instead of just exposing a single 
value. If the scope goes further, yes it may be a waste of time. 
Otherwise though, I think it's more a concern about 
precision/conciseness than it is about an investment of time/resources. 
That said, display technologies are over my head.

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-23 Thread Charles Pritchard

Message: 1
Date: Mon, 22 Nov 2010 15:27:40 -0500
From: Boris Zbarskybzbar...@mit.edu
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Processing the zoom level - MS extensions to
window.screen
Message-ID:4cead23c.1000...@mit.edu
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 11/22/10 12:22 AM, Charles Pritchard wrote:

OpenGL has an immediate-mode which does not require a bitmap backend.

Sure.  But if it's going to be resolution independent, then there needs
to be a retained mode somewhere in the stack, even if it's not exposed
to the original caller (e.g. you GL could be outputting to postscript).
   That is, to have resolution independence, you _have_ to retain more
information about the logical structure of your image than just pixel
color values.

Animated digital imagery usually requires retained data, otherwise it'd 
be analog.

For the topic at hand, canvas, near-all canvas apps retain state data in 
the scripting environment. They have to, to perform a repaint.

Most uses of canvas involve keeping state-info around in order to redraw
the screen.

Quite a number do, yes.  A number don't.

I'll challenge you on this one: I don't think there are a number of them 
that don't.

We may just have a different idea about what the state-info is.

The scripting environment likely keeps around a function, that, when 
called, will re-draw to the canvas.
The output may change, based on environment, but the scripting 
environment is a retained environment.

The browser event loop is intrinsic to the way canvas operates.

It's a requirement for apps which use the full width and height of the
window, as the canvas state resets when the element size is changed.

Sure.  This is the first mention of you resizing your canvas to use the
full width and height of the window, which sounds like the sort of
constraint I asked about in my previous mail

Sorry I missed that one... Resizing a canvas within an element is 
another use case,

or otherwise animating the canvas in any way not covered by CSS.

Right, so you're trying to build a retained-mode something using
canvas as the rendering backend, no?

I'm getting the impression that you don't use the API in your work.

Well, most of my work related to the API is on the C++ end of the
API, making it work (or more precisely, making it work faster).  The
time I spend on that is far greater than the time I spend using it, for
sure.  I _have_ used it, of course; just not for my work.

But I'll note that an ad-hominem attack in response to a technical
question doesn't really get us further towards mutual understanding.

It is a legitimate statement, and relevant to the discussion, though I 
could have phrased it more gently.

The 2D API, as it relates to implementation details -- is a very 
different item than the actual use of that API.

You're looking at fill methods, path checking, clipping, masking, etc. I 
understand that. I've produced several implementations.

I've also produced a substantial body of work using the API; and so, 
speaking from that place, I can say with some credibility that 
programming the API is radically different than using the API.

I appreciate your candor, and can now, better understand your 
perspective/misunderstandings on some of the issues I've brought up.

In this thread, I've only brought up the fact that usingcanvas  with
fillText requires fetching the current DPI ratio,
so that the text is clear and crisp. How is that reinventing the wheel?

Your specific proposal is for achieving resolution-independent rendering
by using canvas + fillText + DPI ratio + firing resize revents on zoom
(and a few you left out, like firing resize events on non-zoom DPI
change when I switch to an external monitor and so forth, but which are
clearly needed to make this whole approach actually work well).

I did consider that  use case; it's a corner-case, and I don't think we 
have the proper support in DOM Windows to even begin to support 
multiple-monitors. I do have some ideas on it, but I think that there 
are more important issues in the present.

In terms of reinventing the wheel, we are talking about a minimum of 
lines of code. We're talking about ~6 lines of code here.

Believe me, I've reinvented wheels. It takes a lot more work.

At the same time, there are existing web technologies whose entire
reason for existence is resolution-independent graphics and text
rendering (SVG, specifically).

SVG is a document format. It is not reliably implemented. It's far more 
expensive to implement SVG on a new environment than Canvas.

Disagreeing with my use case is your choice, but it's about as useful as 
telling the Skywriter team that they're wasting their lives.

What I'm trying to understand is what specific issues with SVG prevent
its use in your situation, and whether those are the implementations
just suck issues or whether they're intrinsic

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-23 Thread Robert O'Callahan

On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard ch...@jumis.com wrote:

   SVG is a document format. It is not reliably implemented. It's far more
 expensive to implement SVG on a new environment than Canvas.


So? You don't have to implement it.


I can't do much for you here other than explain to you what I'm hearing.
 a) Why are you using our Canvas implementation instead of our SVG
 implementation.
 b) Why are you using ctx.fillText('Test') instead of
 element.appendChild(document.createElement('text')).textContent = 'Test'.

 For answers
 a: I'm using it because I work across a variety of browser platforms.
 Canvas is far better supported.


It doesn't make sense to request entirely new features (that by definition
aren't currently supported) because existing features aren't widely
supported.

Anyway, I'm not sure why you think canvas is far better supported than
SVG. What browser supports canvas but not SVG?





 Sure, but there are plenty of canvas uses that aren't animating all the
 time (I've seen image editing apps, sites that use canvas as their
 _input_, not their output, etc).


 1. Name one.


http://arewefastyet.com
http://www.simile-widgets.org/timeplot/
http://jwf.us/blog_apps/mandelbrot_canvas/

Robert's suggestion would radically alter the existing functionality of
 canvas


Only in a way that maintains compatibility with existing content. Otherwise
I wouldn't have suggested it.


 and require a whole lot of work from other vendors.


Not really.

Rob
-- 
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]

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-23 Thread Boris Zbarsky


On 11/23/10 9:30 PM, Charles Pritchard wrote:

Most uses of canvas involve keeping state-info around in order to redraw
the screen.

Quite a number do, yes. A number don't.

I'll challenge you on this one: I don't think there are a number of them
that don't.
We may just have a different idea about what the state-info is.

The scripting environment likely keeps around a function, that, when
called, will re-draw to the canvas.


Are you including things like http://detexify.kirelabs.org/classify.html 
under this classification?



The browser event loop is intrinsic to the way canvas operates.


Um... no.  Not really, no.  You can render stuff (e.g. incoming video 
data) into the canvas, then grab out the resulting PNG data and move on 
without ever keeping any of the state around in your script or the 
canvas or painting it back to the canvas


Unless we're _really_ using different definitions of event loop and 
intrinsic (or operates?).



The API footprint I'm requesting is about the size of a flea.


The thing is, if we add one separate flea for every use case we end up 
with a whole bunch of fleas...  Even if the special API addition is 
small, asking whether it's needed or whether a more general approach is 
preferred is worth it.  The answer will depend on the details, of course 
(like whether there _is_ a sane general approach).



Further, you're still thinking of SVG as though it's software... It's
not. It's a document format.


SVG is just a particular retained-mode representation.  In particular, 
you can script it.  What, precisely, is the difference between 
software and document format, here?


Heck, HTML is a document format; gmail is software that happens to use 
HTML as a presentation layer, right?



I can't do much for you here other than explain to you what I'm hearing.
a) Why are you using our Canvas implementation instead of our SVG
implementation.


... for this specific use case of needing resolution-independent 
rendering.  That last part is key.



b) Why are you using ctx.fillText('Test') instead of
element.appendChild(document.createElement('text')).textContent = 'Test'.


You mean element.appendChild(document.createTextNode(Test)).  But yes, 
that's how you'd script SVG.



a: I'm using it because I work across a variety of browser platforms.
Canvas is far better supported.


OK.  And you think the timeframe for getting convergence on the things 
you need for resolution-independence in canvas is shorter than the 
timeframe for better SVG support, presumably?



b: Because it's shorter


It's pretty easy to set up a helper function...  But yes, the DOM does 
tend to be verbose.



and wrapping from Canvas to SVG automatically is inefficient.


This I'm not sure I follow.


Sure, but there are plenty of canvas uses that aren't animating all the
time (I've seen image editing apps, sites that use canvas as their
_input_, not their output, etc).

1. Name one.


See link above.  I can dig around more if you do want more examples.


2. Flash is a fine technology.


No, not really.


3. Using canvas means having an entry point;
typically in window.onload. They're authored to re-render based on user
input.


See link above.


And, these aren't great lengths. It's about 6 lines of javascript.


Uh...  That depends on how your drawing path is set up.  If I understand 
correctly what you're doing, you have to get the DPI ration (call it N), 
change the canvas width/height by a factor of N, and change all 
coordinates in all your drawing calls by a factor of N, right?



Canvas programmers have, necessarily, an understanding of how Canvas
works. It's an API where nothing is done for you.


This last isn't quite true (e.g. there are plenty of examples of Canvas 
dwim that leads to some weirdness from my point of view).  And it's not 
clear that it must be true; if there are ways to make the API easier to 
use, we should make use of them.



You've got great expectations for the great lengths I'm willing to go.
Wish you had some of that faith in other developers. Canvas coders work
very hard at their craft.


I'm sure they do.

I'm sure HTML coders work hard too.  And JS coders, too.

I have approximately zero faith in JS coders and HTML coders doing 
things right, after fairly extensive exposure to the results of their 
work.


My faith in canvas coders is closer to 0.2 (on a 0-1 scale), largely 
because it's not quite as mainstream yet, so only the more competent 
folks are doing it.



I'm all for easy, but I'm not for restricting users, nor breaking
existing apps.


OK, another point of agreement.


Using that data requires very few lines of code.


Again, that seems to depend on how your drawing is set up, unless I'm 
really misunderstanding what you're doing.


-Boris

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-23 Thread Charles Pritchard


On 11/23/2010 6:46 PM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard ch...@jumis.com 
mailto:ch...@jumis.com wrote:


  SVG is a document format. It is not reliably implemented. It's
far more expensive to implement SVG on a new environment than Canvas.


So? You don't have to implement it.

Google, Microsoft, Apple, do, have to implement it.

As an app designer, my app should work on ~ four different browsers. I 
need my app to work, with what's out there in practice.


And for other environments, I would have to. I've implemented for JVM, 
Active X (thanks Vlad/Mozilla), Flash and .Net.



I can't do much for you here other than explain to you what I'm
hearing.
a) Why are you using our Canvas implementation instead of our SVG
implementation.
b) Why are you using ctx.fillText('Test') instead of
element.appendChild(document.createElement('text')).textContent =
'Test'.

For answers
a: I'm using it because I work across a variety of browser
platforms. Canvas is far better supported.


It doesn't make sense to request entirely new features (that by 
definition aren't currently supported) because existing features 
aren't widely supported.


It's currently supported by Microsoft, and to a lesser extent, WebKit. 
It's not features, it's one feature.
And as you pointed out, it may be supported in FF4; though it's behavior 
is not standardized.


Anyway, I'm not sure why you think canvas is far better supported 
than SVG. What browser supports canvas but not SVG?

AFAIK, FF is the only to support SVG FE.

SVG is a large spec, even SVG Tiny is unevenly implemented.

WebKit had terribly slow SVG support; IEs was non-existent, though it 
was a reasonable task to bring canvas in. I can barely do a nice thing 
in SVG on the iPhone. It takes 20 seconds to load a rendering that takes 
less than one in canvas. These are the reasons why I think canvas is 
better supported. Further, when there are holes, it's easier to work 
around them in Canvas than SVG.


One gaping hole in SVG is repeated elements. I can not reasonably 
implement InkML rendering in SVG. I need David Dailey's replicate tag to 
do it with any real performance:

http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm

In many ways, SVG has some of the same shortcomings as VML.

When it comes to the canvas standard, there are a few holes, no doubt, 
but they are minor. There are some globalCompositionModes that aren't 
touchable, text support needs a backup library for legacy clients, 
shadow isn't a reliable module. That's what I work with.


Again, I don't see SVG/Canvas as at all exclusive. One is high level, 
one is low level, and the high level work takes quite a bit of work.




Sure, but there are plenty of canvas uses that aren't
animating all the
time (I've seen image editing apps, sites that use canvas as their
_input_, not their output, etc).

1. Name one.


http://arewefastyet.com

Uses a second canvas layer for animation.

http://www.simile-widgets.org/timeplot/
I don't know what was meant by sites use canvas as their _input_, not 
their output, but anyway, it does fit the challenge.
Here's a case where no Canvas animation happens. The state is retained, 
but all the repainting is done by either clicking a link to go to a new 
page, or by abusing HTML DIVs.


It has inefficient use of DOM+HTML. The doc is a lot heavier than it 
needs to be. For their code setup, SVG is a better use case. They do 
support VML. They're only using Canvas to draw lines, likely for 
compatibility reasons. Thus the VML hooks.


They do keep a state, and setup to plot live data. They don't use it, 
they have separate links instead. Turning their Live Examples links 
into a select element would have made good sense.


Here's a better implementation of a time plot. Hold shift to click+drag.
http://timepedia.org/chronoscope/

Anyway, I agree, you've named an example.


http://jwf.us/blog_apps/mandelbrot_canvas/
Re-draw button, right there. State vars in private zoom variable. It 
outputs to Canvas.



Robert's suggestion would radically alter the existing
functionality of canvas


Only in a way that maintains compatibility with existing content. 
Otherwise I wouldn't have suggested it.
Existing apps targeting mobile devices (android/iphone) and scaling for 
those devices with the pixel ratio / dpi density variables would be 
broken. It violates a clearly defined separation of roles with CSS and 
Canvas.



and require a whole lot of work from other vendors.


Not really.
Implement it as an extension, let us know how much time was involved. It 
may help other vendors budget their resources.


I'm very uncomfortable with it being used as the standard behavior for 
the existing HTML Canvas element.



-Charles

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-22 Thread Charles Pritchard


On 11/22/10 12:30 AM, Robert O'Callahan wrote:
On Mon, Nov 22, 2010 at 8:49 PM, Charles Pritchard ch...@jumis.com 
mailto:ch...@jumis.com wrote:


On 11/21/10 10:51 PM, Robert O'Callahan wrote:

On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard
ch...@jumis.com mailto:ch...@jumis.com wrote:

I've a deep and detailed understanding of the SVG, HTML, DOM
and CSS specs.


Just out of interest, why aren't you using SVG?

Many thanks for the SVG Filter Effect CSS extension.
I'd like to see that catch on with other vendors.

Implementations of SVG are uneven and/or slow:

Example: SVG Filter Effect + with an animated rotate in FF 3
(excuse me if this is dated)
was quite slow, though the SVG FE implementation is faster than
CanvasPixelArray.
It's also tricky, getting SVG FE turned on (for me anyway), with
the xhtml mime requirements.


That doesn't really explain why you're using canvas, if SVG is faster 
than canvas for your effect.
I wasn't able to freeze the composition of the SVG layer. Upon 
rotation, the SVG layer re-filters the image,
it re-runs the filter effect on each rotation. With canvas, I simply 
re-draw the filtered image

into the rotation.

I don't mean to get caught up in particular platform quirks. It's been a 
few months since I've

addressed SVG ones. SVG FE afaik, was only in FF 3.6 w/ strict reqs.

We target several browsers; so regardless of the merits of SVG in FF 
3.6, we still try to support

FF 3.0 and other legacy browsers and non-gecko browsers.

Simply, Canvas is less expensive to implement, and I'm sure far fewer 
LOC than SVG,
so it's uptake was reasonably quick, and adding it to a new platform is 
reasonably quick.




For both performance and compatibility reasons, we've had to write
low level code anyway.
Actual display calls (be they SVG-able or not) are a relatively
small part of our app.

I'm currently focused on interchangeability of our HTML and Canvas
profiles.
Many SVG features are available via CSS now: paint servers and
gradients,
rounded rectangles, some text effects.

Because of that, we're focused on HTML.
SVG FE is definitely in our code base as a rendering option.
We store our iconography in SVG, and some basic glyphs.
We use canvas to render the glyphs, and we pre-render our
iconography into png.


It's important to separate the issues that are fixable implementation 
limitations from those issues that are fundamental to the design of 
Web standards. There is no point in adding new platform features to 
work around implementation limitations; we get a simpler platform if 
implementors just fix the existing features.


So, for example, I wouldn't want to add canvas features to address 
use-cases for which SVG would work well if it was a bit better 
implemented.
My attention is still on exposing metrics so I can repaint to the device 
resolution, fully within the existing standard. I don't want to change a 
thing about CSS/Canvas; just looking for some data to be available in 
the DOM.


It's a DOM deficiency in relation to the canvas tag.
Google Books demonstrates a use case apart from Canvas. They don't need 
to override the browser's zoom. They do provide their own icon. If the 
browser did provide
information, about zoom, they could send a higher resolution image to 
the browser for that portion.


Here's a good, short, example of an SVG/WebGL+Canvas+HTML+CSS profile:
[canvas style=filter: url(#myPixelFilter); scale(.5,.5)]
Everything is doing exactly what it should.

My only active proposal for the canvas spec is exposing a baseline 
property in TextMetrics. textBaseline is insufficient on its own.



I understand the need to make canvas backing store pixels map to
device pixels when possible. Suppose that, on clearing the canvas
(e.g. by setting the width or height attribute), the browser
automatically set the canvas backing store density so that canvas
backing store pixels map to device pixels (taking into account
the current zoom settings). Suppose further that browsers fired
the 'resize' event when they zoom in a way that changes the
window size (as they should, even if they currently don't). Then
on 'resize' you could clear your canvas and redraw it, and
automatically get a canvas backing store with the right
resolution with no further code changes. Would that address your
use case?

I appreciate your understanding, and your brainstorming.

We currently use downsampled images within our application, and
this proposal would override them We use them where filter effects
are live, and are too expensive for the host to process quickly.
Sampling is also useful as a memory management technique. On a
resource constrained device, for whatever reason, it can make
sense to draw the canvas at a smaller size, even though upscaling
is noticable.

With a complex

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-22 Thread Boris Zbarsky


On 11/22/10 12:22 AM, Charles Pritchard wrote:

OpenGL has an immediate-mode which does not require a bitmap backend.


Sure.  But if it's going to be resolution independent, then there needs 
to be a retained mode somewhere in the stack, even if it's not exposed 
to the original caller (e.g. you GL could be outputting to postscript). 
 That is, to have resolution independence, you _have_ to retain more 
information about the logical structure of your image than just pixel 
color values.



The bitmap backend comes in with ImageData and CanvasPixelArray, and CSS
width/height.


None of those actually require a bitmap backend  (though there 
aren't really very good ways to make putImageData 
resolution-independent, I agree).



Most uses of canvas involve keeping state-info around in order to redraw
the screen.


Quite a number do, yes.  A number don't.


It's a requirement for apps which use the full width and height of the
window, as the canvas state resets when the element size is changed.


Sure.  This is the first mention of you resizing your canvas to use the 
full width and height of the window, which sounds like the sort of 
constraint I asked about in my previous mail



Right, so you're trying to build a retained-mode something using
canvas as the rendering backend, no?

I'm getting the impression that you don't use the API in your work.


Well, most of my work related to the API is on the C++ end of the 
API, making it work (or more precisely, making it work faster).  The 
time I spend on that is far greater than the time I spend using it, for 
sure.  I _have_ used it, of course; just not for my work.


But I'll note that an ad-hominem attack in response to a technical 
question doesn't really get us further towards mutual understanding.



Yes, but if you're trying to build SVG-like features on top of canvas
one has to stop and ask whether just using SVG might be a better idea.
The answer might still be no, of course. But reinventing wheels
usually needs a pretty strong motivation...

I've a deep and detailed understanding of the SVG, HTML, DOM and CSS specs.


Good for you.


In this thread, I've only brought up the fact that using canvas with
fillText requires fetching the current DPI ratio,
so that the text is clear and crisp. How is that reinventing the wheel?


Your specific proposal is for achieving resolution-independent rendering 
by using canvas + fillText + DPI ratio + firing resize revents on zoom 
(and a few you left out, like firing resize events on non-zoom DPI 
change when I switch to an external monitor and so forth, but which are 
clearly needed to make this whole approach actually work well).


At the same time, there are existing web technologies whose entire 
reason for existence is resolution-independent graphics and text 
rendering (SVG, specifically).


What I'm trying to understand is what specific issues with SVG prevent 
its use in your situation, and whether those are the implementations 
just suck issues or whether they're intrinsic to SVG.  Understanding 
that would make it easier for me to balance the additional API footprint 
you seem to think is absolutely and unequivocally necessary, as well as 
the work needed in UAs to add the APIs you want and the resulting impact 
on sites that aren't yours and users of those sites against the pain 
that you would presumably need to endure to use SVG.


Again, if there was a description of this somewhere that I missed, I'd 
love a link.



I haven't requested a whole bunch of new features. Just one.


At the very least, you want resize revents on zoom and an exposure of 
the current DPI, whatever that means.



One related to making text legible.


_This_ I agree is a worthwhile goal.


Because most authors don't think about things like that and won't do
it? So you'll get broken behavior for users in most cases.

Most authors re-render their canvas: all authors which use animation
re-render their canvas


Sure, but there are plenty of canvas uses that aren't animating all the 
time (I've seen image editing apps, sites that use canvas as their 
_input_, not their output, etc).



I haven't requested that we change any behavior. What is going to get
broken ?


You have requested a solution that works to make browser zoom work for 
your particular case.  I'm saying that it might be worth considering 
solutions that work for other cases too, assuming they actually work, 
rather than tailoring the solution to your situation and allowing other 
authors who have the same problem but aren't aware of it, due not having 
a detailed understanding of the SVG, HTML, DOM, and CSS specs, to 
inflict unreadable text on their users by accident.


Specifically, your proposed solution involves some fairly complicated 
manual rescaling of all your canvas drawing on zoom to achieve the 
desired effect.  This is something most authors just aren't going to do. 
 I'm glad you're willing to go to those lengths to make your content

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

2010-11-21 Thread Aryeh Gregor

On Sat, Nov 20, 2010 at 12:21 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
 Most of the use cases for script access to the exact device pixel ratio that
 I've heard boil down to interfere with the user's ability to zoom, which
 is why I haven't been eager to make it easier.

Might there be some web pages that have good reason to interfere with
the user's ability to zoom?  For instance, Google's Quick View for
PDFs:

http://docs.google.com/viewer?a=vq=cache:D8hHb4MTkS4J:www.irs.gov/pub/irs-pdf/fw4.pdf

(Apparently the W-4 form is the first PDF hit when you Google for
PDF, who knew.)  Over at the side there are zoom buttons, but they
do something quite different from using the browser's built-in zoom
function.  However the in-page zoom buttons work is a lot more legible
and smooth than using browser zoom.  So allowing the page to hijack
browser zoom requests in this specific case would actually be a
usability improvement, as far as I can tell.

But I haven't looked at how the page works.  Maybe there'd be some
superior way to do it so that browser zoom worked as well as the
provided zoom buttons.  But users might still expect zoom buttons, so
perhaps zoomIn()/zoomOut() methods would be useful, in the same vein
as print().  (Such methods don't exist yet, do they?  I don't see much
abuse potential if they did -- if you can only say zoom in or zoom
out, they're not good for much except in-page zoom buttons, and you
could emulate the effect through sufficiently tortuous JavaScript.)

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On Mon, Nov 22, 2010 at 10:07 AM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
 wrote:

 On Sat, Nov 20, 2010 at 12:21 AM, Robert O'Callahan
 rob...@ocallahan.org wrote:
  Most of the use cases for script access to the exact device pixel ratio
 that
  I've heard boil down to interfere with the user's ability to zoom,
 which
  is why I haven't been eager to make it easier.

 Might there be some web pages that have good reason to interfere with
 the user's ability to zoom?  For instance, Google's Quick View for
 PDFs:


 http://docs.google.com/viewer?a=vq=cache:D8hHb4MTkS4J:www.irs.gov/pub/irs-pdf/fw4.pdf

 (Apparently the W-4 form is the first PDF hit when you Google for
 PDF, who knew.)  Over at the side there are zoom buttons, but they
 do something quite different from using the browser's built-in zoom
 function.  However the in-page zoom buttons work is a lot more legible
 and smooth than using browser zoom.  So allowing the page to hijack
 browser zoom requests in this specific case would actually be a
 usability improvement, as far as I can tell.


I don't mind a browser allowing a page to override the default behavior of a
browser's zoom keybindings or possibly even menu items. But ultimate control
still has to reside with the user and user-agent. Web designers are
notorious for declaring that their content should be viewed at a certain
size; if an obnoxious designer tries to disable browser zooming, I insist
that the browser be able to override that.

Rob
-- 
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]

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard ch...@jumis.com wrote:

 Rob: Mobile deployments using dpiPixelRatio (as has been adopted by Moz and
 Webkit) and target-DpiDensity work well on the mobile, they are not hooked
 to zoom on the desktop,


It is in Firefox.


 and they were not designed for desktop-style zoom. Trying to overload these
 variables leads to difficulties between the various mobile style zooms and
 desktop zoom.


I'm not sure why. Device-pixel-ratio should give you the ratio of device
pixels to CSS pixels, full stop. You can use matchMedium to use it from JS.

Rob
-- 
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]

Re: [whatwg] Processing the zoom level - MS extensions to window.screen


On 11/21/10 4:12 PM, Robert O'Callahan wrote:
On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard ch...@jumis.com 
mailto:ch...@jumis.com wrote:


Rob: Mobile deployments using dpiPixelRatio (as has been adopted
by Moz and Webkit) and target-DpiDensity work well on the mobile,
they are not hooked to zoom on the desktop,


It is in Firefox.

and they were not designed for desktop-style zoom. Trying to
overload these variables leads to difficulties between the various
mobile style zooms and desktop zoom.


I'm not sure why. Device-pixel-ratio should give you the ratio of 
device pixels to CSS pixels, full stop. You can use matchMedium to use 
it from JS.



I'll give it a run. I'm not up on the 4.x branch.

I would point out that the MS proposal has an independent X and Y 
scaling mechanism.


I believe that dpi ratio is simply set to 2 (or .5... sorry a bit 
rusty) on the iOS 4 retina display.

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On Mon, Nov 22, 2010 at 1:40 PM, Charles Pritchard ch...@jumis.com wrote:

 I would point out that the MS proposal has an independent X and Y scaling
 mechanism.


Does anyone know of any modern displays which have different X and Y
resolution?


 I believe that dpi ratio is simply set to 2 (or .5... sorry a bit rusty)
 on the iOS 4 retina display.


There will be cases where zooming doesn't change device-pixel-ratio. Mobile
browsers tend to have a fast zoom out which doesn't change the layout
(mostly), and that might not change device-pixel-ratio. I think that's OK
for your use cases as long as device-pixel-ratio reports the ratio as if the
page is zoomed in.

Rob
-- 
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]

Re: [whatwg] Processing the zoom level - MS extensions to window.screen


On 11/21/10 4:56 PM, Robert O'Callahan wrote:
On Mon, Nov 22, 2010 at 1:40 PM, Charles Pritchard ch...@jumis.com 
mailto:ch...@jumis.com wrote:


I would point out that the MS proposal has an independent X and Y
scaling mechanism.


Does anyone know of any modern displays which have different X and Y 
resolution?
I've seen more than one LCD-style wide-screen TV which does, but it's 
not so modern anymore.
Beats me. Perhaps MS can chime in with some use cases, as they have 
broad experience with alternative

displays. I doubt this is a mainstream issue, but it may still be an issue.


I believe that dpi ratio is simply set to 2 (or .5... sorry a
bit rusty) on the iOS 4 retina display.

There will be cases where zooming doesn't change device-pixel-ratio. 
Mobile browsers tend to have a fast zoom out which doesn't change 
the layout (mostly), and that might not change device-pixel-ratio. I 
think that's OK for your use cases as long as device-pixel-ratio 
reports the ratio as if the page is zoomed in.
I'll review the current use of dpi ratio in Firefox 4 and get back to 
the list on it.


At the very least, I'd like to make sure the proper routines are 
specified in the specs.
zoom does trigger a layout change, and a resize event. And that's 
fine. If it's not specifically stated in the specs, I'd like it to be.


Following that, we do need a reliable way to grab screen metrics. If dpi 
ratio is reliable, I'm happy to use it.


My concern is that existing implementations of DPI have broken the 
variable for zoom uses.
I do realize that other people screwing up their implementation of the 
standard doesn't mean we should have to change the standard.


At the very least, it means we should update the standard to more 
explicitly define its behavior.


I'm eager to get this functionality met, as legible zoom is very 
important to me, and the current
collection of browsers is completely fragmented in its 
exposure/implementation.


Thanks for working with me on it.

-Charles

Re: [whatwg] Processing the zoom level - MS extensions to window.screen


On 11/21/10 6:30 PM, Boris Zbarsky wrote:

On 11/21/10 8:31 PM, Charles Pritchard wrote:

Canvas is an immediate mode rendering framework. I realize that it uses
a bitmap backend,


Isn't that more or less a requirement for immediate mode?  After 
all, the whole issue is that when resolution changes you need to 
rerender from some sort of state you have around, which is precisely 
what immediate mode doesn't have.

OpenGL has an immediate-mode which does not require a bitmap backend.

The bitmap backend comes in with ImageData and CanvasPixelArray, and CSS 
width/height.

I'm not proposing altering any of those specs or behaviors.

Most uses of canvas involve keeping state-info around in order to redraw 
the screen.
It's a requirement for apps which use the full width and height of the 
window,

as the canvas state resets when the element size is changed.


but the drawing itself works very much like vector imaging. The scene
graph is built in the scripting environment instead of an ML file.


Right, so you're trying to build a retained-mode something using 
canvas as the rendering backend, no?

I'm getting the impression that you don't use the API in your work.



Canvas is a low level API, SVG is a serialized format of a scene graph.
They're not the same thing.


Yes, but if you're trying to build SVG-like features on top of canvas 
one has to stop and ask whether just using SVG might be a better idea. 
The answer might still be no, of course.  But reinventing wheels 
usually needs a pretty strong motivation...

I've a deep and detailed understanding of the SVG, HTML, DOM and CSS specs.

In this thread, I've only brought up the fact that using canvas with 
fillText requires fetching the current DPI ratio,

so that the text is clear and crisp. How is that reinventing the wheel?



While Apple has certainly worked in supersampling, it's completely
unnecessary.


Well, it's unnecessary if we introduce a whole bunch of other features 
and extra work, right?
My comments about Apple unnecessary.. Apple's work on supersampling is 
related to some of their use cases in their platform ecosystem.


I haven't requested a whole bunch of new features. Just one. One related 
to making text legible.



I don't see why expecting a page to re-render is unreasonable.


Because most authors don't think about things like that and won't do 
it?  So you'll get broken behavior for users in most cases.
Most authors re-render their canvas: all authors which use animation 
re-render their canvas,


I haven't requested that we change any behavior. What is going to get 
broken ?



Stated succinctly: It is entirely reasonable to re-render canvas when an
onresize event is received,


It's reasonable to do it.  It doesn't necessarily seem reasonable to 
_force_ everyone to do that to get reasonable zooming behavior...
There seems to be some misunderstanding. Nobody has proposed a change to 
the existing spec,
nor forcing anyone to do anything. I've pointed out a defect, a missing 
property which should be exposed.


Exposing that property changes nothing in existing zooming behavior.

It permits management of resolution targeted bitmaps.


it's a standard practice. There's no reason for the UA to handle it any
differently than it does now (scaling the CSS pixels).


Well, no reason other than making all pages accessible when zoomed and 
not just the rare few that go out of their way to jump through hoops 
to handle it, right?



I don't understand your statement. UA behavior should not be changed.


My evidence is essentially nullified when you make broad statements
about how there are better tools and better formats.


I'm saying that if we're going to add features to the web platform we 
should be making sure they're the right features to add and that 
they're the best ways to solve the problems that need solving.  Maybe 
adding information about the number of canvas backing store pixels per 
CSS pixel (which may NOT be the same as the number of screen pixels 
per CSS pixel, note!) is the right thing to do.  Maybe we need to 
expose both numbers (e.g. exposing the canvas backing store resolution 
will do nothing for your server-generated PNGs).  Clearly just 
exposing the screen resolution doesn't work for canvas in a world 
where we don't guarantee that canvas and screen resolutions match.

This is helpful. Now we're moving forward.

Your team has made certain that the information exposed in 
window.screen matches CSS pixels. I understand that was a design 
decision. Other vendors have opted to have screen match OS settings. 
Currently, window innerWidth/outerWidth and window.screen are 
implemented in too many different ways. Perhaps in the future there will 
be some agreement about it.


I'd certainly like this particular defect re: canvas/pixel density to be 
addressed right the first time, and I know that may mean waiting for 
other issues to be resolved.


Microsoft's proposal hits the issue with six variables; it may be

Re: [whatwg] Processing the zoom level - MS extensions to window.screen

On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard ch...@jumis.com wrote:

 I've a deep and detailed understanding of the SVG, HTML, DOM and CSS specs.


Just out of interest, why aren't you using SVG?

I understand the need to make canvas backing store pixels map to device
pixels when possible. Suppose that, on clearing the canvas (e.g. by setting
the width or height attribute), the browser automatically set the canvas
backing store density so that canvas backing store pixels map to device
pixels (taking into account the current zoom settings). Suppose further that
browsers fired the 'resize' event when they zoom in a way that changes the
window size (as they should, even if they currently don't). Then on 'resize'
you could clear your canvas and redraw it, and automatically get a canvas
backing store with the right resolution with no further code changes. Would
that address your use case?

Rob
-- 
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]

Re: [whatwg] Processing the zoom level - MS extensions to window.screen