Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Jul 16, 2013 at 6:41 PM, Ian Hickson i...@hixie.ch wrote:
This thread was gigantic and involved many proposals. I've only included
the last one below, since it seemed to take into account the most of the
feedback mentioned on the thread; I haven't responded to all the
intermediate e-mails which were mainly just a discussion amongst
contributors, and not direct feedback on the spec itself.
I haven't yet changed the spec. The main thrust of the feedback below ends
with the proposal to use WebGL's 'alpha' feature for the 2D context; is
this what implementors want to do?
We're implementing this in Chromium (currently behind the experimental
canvas features flag).
[...]
On Fri, 15 Feb 2013, Stephen White wrote (with roc's annotations inline
prefixed with | and mine inline not prefixed):
So let me take a stab at a brief summary of the proposals so far, and
the pros and cons of each (correct me if I missed anything):
opaque attribute or matteColor property
pro: fairly easy to implement
pro: no performance hit over regular rendering
pro: many opportunities for optimization
pro: catches all in-canvas cases of color fringing
con: does not handle any out-of-canvas color fringing
con: opt-in
| con: requires changes to canvas compositing spec and possibly
| implementations.
automatic opacity detection
pro: catches most (all?) cases of in-canvas color fringing
pro: some opportunties for optimization (must be conservative in some
cases)
con: does not catch color fringing on CSS transforms, canvas - WebGL,
etc
context.textAntialising = { 'none', 'grayscale', 'subpixel' }
pro: very easy to implement
pro: no performance hit
con: does not catch any cases of color fringing; completely up to web
developer
con: opt-in
| con: requires specification and implementation of what happens when
| subpixel AA is drawn over transparent background.
collect commands into a buffer, flush buffer only when compositing
canvas to page, and decide on subpixel AA at that point.
pro: catches all cases of color fringing
con: in some cases, requires an infinite buffer (e.g., a canvas that
never clears, and only accumulates drawing frame-to-frame means
you must accumulate commands indefinitely)
or giving up and using grayscale at some point
con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
con: may introduce performance hit due to re-rendering with and without
subpixel AA (in cases where you would rather have just gone
without)
con: doesn't handle pixel manipulation cases (since you can't return
two sets of pixels and you can't regenerate the stuff that script
is generating based on the returned pixels)
two buffers (one grayscale, one LCD AA)
pro: handles all cases of color fringing
pro: moderately easy to implement
con: RAM (or VRAM) usage is doubled
con: possibly-unnecessary performance hit
con: must be opt-in
[...]
On Wed, 20 Feb 2013, Rik Cabanier wrote:
So now we have:
- don't do this on pinch-zoom devices
- don't do this for HW accelerated canvases
- don't do this if the canvas dpi doesn't match the screen
- don't do this if there are transforms
- authors will have to be very careful when using this feature since it
can
turn on or off or cause rendering glitches.
Is it still worth pursuing this?
On Thu, 21 Feb 2013, Stephen White wrote:
I believe it is. Even with those constraints, there are a large number
of applications which can benefit from text which looks as good as the
native platform can provide.
That said, I also think Robert is right that we should not spec out
precisely when subpixel AA text will occur in any of these automatic
modes, since:
1) there are some platforms/devices which don't do LCD text at all
2) It may be too restrictive for the browser implementor, e.g., they
may be essentially required to implement deferred rendering or two
backing stores in order to meet the resulting spec, which seems
onerous
Subpixel AA text aside, I still think it's worth spec'ing out mozOpaque,
if only just for the optimization opportunities that we don't get with
an automatic solution (e.g., putImageData). Its implementation is
fairly straightforward (much more so than the other options above), and
it won't break any existing content.
To me, the it breaks compositing argument falls into the doctor, it
hurts when I do this category: the user is specifically opting into an
opaque backing store, and so the changes in behaviour for compositing
modes which reference destination alpha are expected, just as they are
when using DST_ALPHA blending modes in a WebGL context created with the
alpha attribute set to false.
On Fri, 22 Feb 2013, Robert O'Callahan wrote:
I think Rik is convincing me that we shouldn't
[whatwg] Background of body covering the whole page – is this described somewhere?
Browsers seem to be rather consistent in applying the background
properties of the body element, if set, to the entire viewport, even if
e.g. the height of the body is explicitly set to a small value. Example:
!doctype html
title/title
style
body { background: green; height: 2em; }
/style
Hello world.
The entire viewport has green background. If I add
html { background: white }
to the style sheet, things change radically (to match expectations).
This also affects background images.
This sounds odd, since the body element is a child of html, so we should
expect the html element background shine thru if the body element has
transparent background, not vice versa.
Is this described somewhere in HTML or CSS specifications or drafts? I
think it should be, since it is what browsers do (tested on Firefox,
Chrome, IE), and even though it sounds absurd, I’m afraid pages may rely
on it. A natural place to look at is
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-page
but I can’t find any statement about the body element extending to cover
the viewport as far as backgrounds are considered.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Background of body covering the whole page – is this described somewhere?
On Tue, Jul 23, 2013 at 10:37 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Is this described somewhere in HTML or CSS specifications or drafts? I think it should be, since it is what browsers do (tested on Firefox, Chrome, IE), and even though it sounds absurd, I’m afraid pages may rely on it. A natural place to look at is http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-page but I can’t find any statement about the body element extending to cover the viewport as far as backgrounds are considered. http://www.w3.org/TR/CSS2/colors.html#background -- http://annevankesteren.nl/
Re: [whatwg] Feedback on a variety of elements
On Mon, 31 Dec 2012, Pierre Dubois wrote: On Fri Dec 14 2012, Ian Hickson wrote: I don't think this works for all tables. For example, the first example in the spec in the th element's section does not get handled correctly by your algorithm -- it treats the ID column as important, instead of the second column. [Maybe I] did not [use] the correct word to identify that kind of cell that I named Key cell. The objective of the Key cell is to identify a td cell that have [...] relationships to a th cell at his right side in the same row. The td rowspan attribute would need to match or be lower than the corresponding th. The inverse would show a data cell td used as an heading cell th. If I understand correctly, you mean that you want to be able to automatically determine that the th here is a heading for the td: table tr td th /table The current relationships algorithm create a relationship for the preceding th cell not following th cell. Assuming you mean the one in the spec today: correct. That's partly because you never want to do this vertically, and the algorithm is direction agnostic (it uses the same steps for going left as going up), and partly because it's not clear how often you want to do this going left either. In particular, sometimes tables are of the form: +-+-+-+-+ | Header | Data| Header | Data| +-+-+-+-+ ...where the header cells are headers for the data to the right. Or, in a more difficult case to handle: +-+-+--+-+ | Header v| Header v| Metaheader v | | +-+-+--+-+ | Data| Data| Header | Data| +-+-+--+-+ | Data| Data| Header | Data| +-+-+--+-+ Without the scope= attributes, I don't think that table would make much sense. You have right that the proposed algorithm, for the first example in the spec in the th element's section does not get handled correctly. The question is: Why from a visual point of view, by excluding any styling, can you feel that Cats cell and the English speakers cell is know as a row group as highlighted in the source code with the scope attribute set to rowgroup? My answer is: Because the header cell is surounded by empty data cell in his row. For me that represent a mix of a layout table combined with a data table. A quick fix to the proposed algorithm would be at the end of the data row processing, do a test to know if the header cell is surrounded by empty data cell, that until the first real data row is found in the rowgroup (tbody) section. If that is true, the header cell scope can be determined as a rowgroup header and the surrounded empty data cell can be know as layout cell. Is that make sense? Have you another visual logic regarding that case? I don't know that we really need, or want, to make the current algorithm more magic than it already is. There's a point of diminishing returns where the complexity makes it too hard to debug. The algorithm is already pretty complex, maybe too much so; making it even more complex seems like a bad idea. Proposal: Table Usability API This is a very elaborate and large API. What are the use cases against which to evaluate it? i.e. what problem does it solve? The main use case is to parse a complex table and extract the data in the objectif to create an accessible (WCAG 2.0 Level AA compliant) chart by using the progressive enhancement strategy. The use of the table to create the chart remove the need for an web author to discus and sometime debate with the content provider in the objectif to build a descriptive text alternative version of the chart. Why can't this be done in script already? I don't understand why we need an API for this. Also the proposed Table Usability API is not just to handle complex table. The proposed API provide support access the tabular data either by his row or by his columns. Sometime, for presentational purpose, the axes are reversed. As an example took the following two row table. Do you think, for presentational purpose, it will be better have a two column table instead? I think both table, with equivalent structure, should be supported and have an equivalent accessible API. [long table] It's not clear to me that you need an API at all. The DOM API seems sufficient for this example. I mean, people hardly use the API we have already, why add another one, especially a big one? It just doesn't seem like a compelling enough problem for us to try to solve it. On Fri, 19 Oct 2012, Pierre Dubois wrote: Sometime the subsequent
Re: [whatwg] Page reflow when entering/exiting fullscreen
On Mon, Jul 22, 2013 at 6:58 PM, Matt Falkenhagen fal...@chromium.org wrote: When an element goes fullscreen, should the browser try to retain the layout of the underlying document, e.g., by creating a placeholder for the element? It's not entirely clear to me what you mean by placeholder. With the top layer, it's possible to style the fullscreened element and ::backdrop such that the underlying document is visible. In such a case, it may be surprising for the user to see the layout change. The scroll position may also change. As far as I can tell, the Fullscreen spec doesn't say anything normative about retaining the layout. I'm wondering whether it was a deliberate decision to leave it up to the author to create a placeholder if desired. (As an implementer, this would be easier for me.) I had not entirely considered scroll position. I sort of assumed that would not change, but maybe that's not the best behavior. I don't really have strong opinions here. WebKit and Blink actually already use a placeholder to prevent the page from reflowing when entering/exiting fullscreen, but there are some limitations. For example, inline elements don't get placeholders. -- http://annevankesteren.nl/
Re: [whatwg] Background of body covering the whole page – is this described somewhere?
2013-07-23 20:44, Anne van Kesteren wrote: On Tue, Jul 23, 2013 at 10:37 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Is this described somewhere in HTML or CSS specifications or drafts? I think it should be, since it is what browsers do (tested on Firefox, Chrome, IE), and even though it sounds absurd, I’m afraid pages may rely on it. A natural place to look at is http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-page but I can’t find any statement about the body element extending to cover the viewport as far as backgrounds are considered. http://www.w3.org/TR/CSS2/colors.html#background Thanks for the prompt reply. Makes things clear. On the practical side, however, I wonder whether this part of CSS specifications should be referred to in the Rendering section, as it is logically rather unexpected. Yucca
Re: [whatwg] Page reflow when entering/exiting fullscreen
On Tue, Jul 23, 2013 at 11:19 AM, Matt Falkenhagen fal...@chromium.org wrote: By placeholder, I mean a dummy renderer with the same dimensions as the element before it went full screen, added in its place when it goes fullscreen to prevent the page from reflowing. There are probably other ways to prevent reflow, such as rendering the element twice, once in fullscreen form and once as it would appear had it not gone fullscreen (though that would be a lot more difficult). If I understand correctly, the spec isn't mandating anything about retaining or not retaining layout, but I'd like to just get an idea of what people expect to happen. I would expect layout to happen and I would expect the scrolling position to not change (or if you decide to scroll when fullscreen, it would). The placeholder thingie might make sense to make the appearance of entering and exiting fullscreen more smooth. -- http://annevankesteren.nl/
Re: [whatwg] `window.location.origin` in sandboxed IFrames.
On Thu, 10 Jan 2013, Mike West wrote: In WebKit, loading 'iframe sandbox=allow-scripts src=frame.html/iframe' with a framed document containing 'scriptalert(window.location.origin);/script' alerts the actual origin of the document, which wasn't what I expected. I'm not sure what's intended, but I expected that treating the framed document as existing in a unique origin would have some effect on the string output as it's location's origin. Adam explained that WebKit currently treats the 'origin' attribute as the origin of the document's location, not the origin of the document[1]. This is generally benign, but surprised me in the sandboxed case. What should the expected behavior in this case be? Given the way that MessageEvent sets the origin of a message from a sandboxed frame to the string null, that seems like a reasonable option here as well. I guess we have to decide whether location.origin is exposing information about the location, or information about the page. Since it's on Location, I think it'd make sense to be information about the location; document.origin would be where I'd expect information about the page itself. When the page's origin doesn't match the URL's origin, the page's origin will always just serialise as null, so it's not clear that it's actually useful to expose that really anyway. What would the use cases be? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch: Origin header
On Wed, 6 Mar 2013, Anne van Kesteren wrote: It seems we have a bunch of different policies for setting the Origin header :-( XMLHttpRequest always sets it to the given value. HTML's fetch only sets it to a non-null value if a from parameter is passed. I originally wanted it to always be passed, but there are cases where that's not done for various reasons (mainly privacy or compatibility). The Origin spec handles this via privacy-sensitive contexts; if you look at the HTML spec source and search for privacy-sensitive you'll find relevant notes. HTML's potentially CORS-enabled fetch seems to never invoke fetch with a from parameter except indirectly via CORS' cross-origin request. Right, the idea there is to basically defer to CORS. On Thu, 7 Mar 2013, Anne van Kesteren wrote: So I also tested the fetch from an origin in the specification http://dump.testsuite.org/fetch/form.html and it turns out that only WebKit exhibits this behavior. Other browsers do not include Origin in a navigation that uses the POST method. This is unsurprising, it's new requirements in old parts of the spec and it's unlikely browsers will be updated until it's something we test in the test suite. On Fri, 8 Mar 2013, Anne van Kesteren wrote: Okay. So currently the mix of the Origin specification and the HTML specification suggests you either do Origin: /origin/ or Origin: null. However WebKit seems to do Origin: /origin/ or no header at all (for the privacy-sensitive cases). Ian also mentioned that we can not just put the Origin header into every outgoing request as that breaks the interwebs (per research you did for Chrome I believe?). Origin: null is what the Origin spec requires, I think, so we should update that spec if we don't do that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox and allow-scripts
On Fri, 12 Apr 2013, Ian Melven wrote:
Freddy Braun recently noticed that he could do the following in Firefox
:
iframe id='foo' sandbox='allow-same-origin' src='inner.html'
(note no allow-scripts)
and then in the document containing the iframe:
var iframe = document.getElementById('foo');
iframe.contentWindow.eval(alert(document.location));
and the alert will fire, which he found surprising.
I tested this in Chrome and IE 10 and found the behavior consistent
across all three browsers.
The relevant portion of the spec seems to be (from
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#enabling-and-disabling-scripting)
:
* Scripting is enabled in a browsing context if ... The browsing
context's active document's active sandboxing flag set does not have its
sandboxed scripts browsing context flag set.
is the intent in Freddy's case to apply this rule using the browsing
context of the script entry point ? that fits the implemented behavior,
but maybe should be mentioned in the iframe sandbox/allow-scripts
section of the spec ?
On Sat, 22 Jun 2013, Adam Barth wrote:
That's the behavior I would expect. You can also do the following:
var iframe = document.getElementById('foo');
iframe.contentWindow.alert(hello);
The allow-scripts sandbox flag doesn't block the script interfaces
inside the iframe. It just prevents content inside the iframe from
triggering script execution. In this case, the content outside the
iframe is the one triggering the script execution.
I agree with Adam that executing the eval() is consistent with the HTML
spec. The reasoning is that the eval is done by JavaScript itself, which
doesn't check if scripting is enabled when it runs the script. The
scripting-is-enabled stuff is only checked when HTML itself tries to
compile or run a script, e.g. in a script block or event handler.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Page reflow when entering/exiting fullscreen
On Mon, 22 Jul 2013, Matt Falkenhagen wrote: When an element goes fullscreen, should the browser try to retain the layout of the underlying document, e.g., by creating a placeholder for the element? With the top layer, it's possible to style the fullscreened element and ::backdrop such that the underlying document is visible. In such a case, it may be surprising for the user to see the layout change. The scroll position may also change. As far as I can tell, the Fullscreen spec doesn't say anything normative about retaining the layout. I'm wondering whether it was a deliberate decision to leave it up to the author to create a placeholder if desired. (As an implementer, this would be easier for me.) WebKit and Blink actually already use a placeholder to prevent the page from reflowing when entering/exiting fullscreen, but there are some limitations. For example, inline elements don't get placeholders. How would you know how to style the placeholder? e.g. if you change the body font-size while full-screen, and the element that is now full-screen was, previously, styled using 'em' units or some such, but is now styled using pixels or %s? Or if there was something based on :hover, or dynamic class changes, e.g. every element on the page is styled using explicit pixel dimensions, with one dimension when the elements have class A, and another when they have class B, and the page changes all the elements to class B -- how do you know that in this case, you should update the placeholder? This seems hard to define. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, 22 Jul 2013, Dirk Schulze wrote: scale(0) is invalid, and should throw an exception. I don't think that we want to throw an exception on scale(0). No browser does that today. WebKit did it in some places in the past but removed the exceptions. WebIDL says it should throw a TypeError, because it's missing an argument. (Step 4 of the overload resolution algorithm). Firefox, Chrome, and Safari all seem to do this. The second does setTransform(0,0,0,0,0,0), which should reset the CTM to a zero matrix (again, not invertible). IE, Opera and FF draw a line to 0,0 and close the path afterwards (which kind of makes sense, since the universe is convoluted to one point). WebKit refuses the lineTo command and closes the path as expected. WebKit seems to just be wrong here, and the others right. Since this is not written in the spec As far as I can tell, it _is_ written in the spec. scale(0,0) would reduce all coordinates and lines and so forth to 0,0. That's what the spec requires. I don't see the problem here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Background of body covering the whole page – is this described somewhere?
On Tue, 23 Jul 2013, Jukka K. Korpela wrote: 2013-07-23 20:44, Anne van Kesteren wrote: On Tue, Jul 23, 2013 at 10:37 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Is this described somewhere in HTML or CSS specifications or drafts? I think it should be, since it is what browsers do (tested on Firefox, Chrome, IE), and even though it sounds absurd, I’m afraid pages may rely on it. A natural place to look at is http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-page but I can’t find any statement about the body element extending to cover the viewport as far as backgrounds are considered. http://www.w3.org/TR/CSS2/colors.html#background Thanks for the prompt reply. Makes things clear. On the practical side, however, I wonder whether this part of CSS specifications should be referred to in the Rendering section, as it is logically rather unexpected. There's a lot of these kinds of things (e.g. lots of things are dependent on quirks mode, there's a bunch more like the background that are dependent on the MIME type, etc). Short of duplicating the entire CSS spec in the HTML spec (which would be my preference, modulo logistics around editing -- I think we should just have one Web spec), it seems impractical to actually mention all of them in the HTML spec. This is why we don't list them currently. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] menu and friends
On Mon, 31 Dec 2012, Jonas Sicking wrote: On Fri, Dec 28, 2012 at 11:07 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 Dec 2012, Jonas Sicking wrote: I don't think it's a good solution to leave it undefined if all/none/some of the UA menuitems are displayed by default. While it on an API level won't break anything, authors consider as breaking a lot more things than APIs not behaving as expected. I'm happy to give guidance that happens to match what the browser vendors want to do anyway, but I don't think it makes sense to make a page- undetectable UI detail like this a conformance requirement. I agree that defining exact UI is a bad idea. However I think we should define the semantic meaning of the context menu. If the semantics are that the context menu provided by the page is intended to be additional context actions, or alternative context actions. I've tried to add more text to the spec to encourage UAs to not show the UA menu items as prominently. Is that sufficient? We're constrained in what we can do, given that this is UI stuff. So are you proposing that the default should be that no UA menu options are displayed. I.e. the default being as if nodefault was set? As a user, I would hate that. But if you as a browser vendor are telling me as a spec writer that this is what would be needed to convince authors to not use divs for context menus, then yes. What I was saying as a browser vendor is that I don't think that authors are going to use this feature unless it provide the ability to replace the existing context menu. Or at least almost entirely replace it. Sure. Honestly, though, I think the bigger blocker right now is that there's only one implementation (and it doesn't match the spec). You are the one that is requesting that we only have a single mode. Well, I think in general it's pretty uncontroversial that, all other things being equal, APIs are better if they have less surface area. So sure, I'd rather we not have multiple modes if we don't need them. If we are to fulfill both these requirements then yes, we end up with something that both you and I would hate in many cases. The alternative that I have proposed, but that you so far have rejected, is the ability for the author to select mode, i.e. select if he/she wants to replace or add to the existing menu. If the options are: - authors never use the feature - users lose their control over their browser - the feature has a complicated API ...then we're stuck in a bad place, certainly. But I don't think those are the only options; what about these, for instance: - authors use the feature anyway, and like that it gives users power - browsers default to showing mainly the author's menuitems, but offer a discoverable way for users to find more options if they need them Ok, the first of these two might be too optimistic, but the second should be workable, no? That's what the spec now suggests. I've added an example that shows how this could work: Before (only the author's commands): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-collapsed.png After (the user having clicked a disclosure widget): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-expanded.png As a user, what I would like to be the behaviour, without the ability for the author to override it, is for the context menu to have the author's context menu items plus the context-sensitive items that cannot be accessed via the regular menus (e.g. Inspect Element, View Image, Copy Link Location, that kind of thing). The ability to override the authors request of replacing the context menu seems like a quality of implementation issue. For example I would imagine that Firefox would hook up the already existing allow authors to replace context menu UI option to control whether the nodefault attribute was honored. Likewise chrome could supply an extension to do the same thing. Personally, I don't want to prevent authors from providing me with features. I just want to prevent them from removing features. What I want is the union of the site's features and the browser's features. Firefox's allow authors to replace context menu UI option is IMHO insufficient. I guess I could live with that as long as there was a way for the page to opt in to displaying items. It would allow adding more finegrained control over which categories of menu items are turned backed on which could be neat. I'm very skeptical about adding any kind of control here before we have broader implementation experience. Once we do, then it will be revisited anyway, since we have this bug on file: I doubt that I can change your mind on this. But I'll note that that means that that likely means that we'll have to make the default behavior the behavior that you like less. I think it's possible to have a default behaviour that
[whatwg] Blurry lines in 2D Canvas (and SVG)
All, we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, but ideally this should never happen. Is this behavior specified somewhere? Is there a way to turn this off?
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
Hi Rik, Just affirming what you've said in SVG: http://cs.sru.edu/~ddailey/svg/edgeblurs.svg The middle rects are crisp, having been merely translated leftward and downward by half a pixel. Zooming in from the browser rectifies the problem (as expected) after a single tick. I remember folks discussing sub-pixel antialiasing quite a bit on the SVG lists circa fall/winter 2011. It seemed to cause some troubles for D3. Is that the same issue? Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rik Cabanier Sent: Tuesday, July 23, 2013 7:19 PM To: wha...@whatwg.org Subject: [whatwg] Blurry lines in 2D Canvas (and SVG) All, we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, but ideally this should never happen. Is this behavior specified somewhere? Is there a way to turn this off?
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
(2013/07/24 8:19), Rik Cabanier wrote: we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ As discussed with Rik privately, SVG has shape-rendering: crispEdges for this.[1] [1] http://www.w3.org/TR/SVG11/painting.html#ShapeRenderingProperty
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Wed, 24 Jul 2013 01:18:35 +0100, David Dailey ddai...@zoominternet.net wrote: Just affirming what you've said in SVG: http://cs.sru.edu/~ddailey/svg/edgeblurs.svg The middle rects are crisp, having been merely translated leftward and downward by half a pixel. Zooming in from the browser rectifies the problem (as expected) after a single tick. I remember folks discussing sub-pixel antialiasing quite a bit on the SVG lists circa fall/winter 2011. It seemed to cause some troubles for D3. Is that the same issue? It's not a bug, it's a feature ;) The line is centered around edge of the box. You haven't specified whether you want the line to be outside or inside the box (or overlapping left edge of the box, but not the right, etc.), so you get line in the middle approximated as well as possible. It's not intuitive. It's a pretty common pitfall, but it's logical. For 1-pixel lines it could be fixed by allowing authors to specify that path should be stroked with lines aligned to inside/outside of the path (which is a useful feature on its own). -- regards, Kornel
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
yeah, at first blush that seemed what was needed. However, this simply turns off antialiasing completely so regular artwork looks terrible. On Tue, Jul 23, 2013 at 5:31 PM, Brian Birtles bbirt...@mozilla.com wrote: (2013/07/24 8:19), Rik Cabanier wrote: we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ As discussed with Rik privately, SVG has shape-rendering: crispEdges for this.[1] [1] http://www.w3.org/TR/SVG11/**painting.html#**ShapeRenderingPropertyhttp://www.w3.org/TR/SVG11/painting.html#ShapeRenderingProperty
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
(2013/07/24 10:07), Rik Cabanier wrote: yeah, at first blush that seemed what was needed. However, this simply turns off antialiasing completely so regular artwork looks terrible. That's a quality of implementation issue. The description of the property value says, Indicates that the user agent shall attempt to emphasize the contrast between clean edges of artwork over rendering speed and geometric precision. To achieve crisp edges, the user agent might turn off anti-aliasing for all lines and curves or possibly just for straight lines which are close to vertical or horizontal. Also, the user agent might adjust line positions and line widths to align edges with device pixels. I'm not sure what use case you have in mind though. Perhaps it's something that doesn't fit that description?
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Tue, Jul 23, 2013 at 5:34 PM, Kornel Lesiński kor...@geekhood.netwrote: On Wed, 24 Jul 2013 01:18:35 +0100, David Dailey ddai...@zoominternet.net wrote: Just affirming what you've said in SVG: http://cs.sru.edu/~ddailey/**svg/edgeblurs.svghttp://cs.sru.edu/~ddailey/svg/edgeblurs.svg The middle rects are crisp, having been merely translated leftward and downward by half a pixel. Zooming in from the browser rectifies the problem (as expected) after a single tick. I remember folks discussing sub-pixel antialiasing quite a bit on the SVG lists circa fall/winter 2011. It seemed to cause some troubles for D3. Is that the same issue? It's not a bug, it's a feature ;) The line is centered around edge of the box. You haven't specified whether you want the line to be outside or inside the box (or overlapping left edge of the box, but not the right, etc.), so you get line in the middle approximated as well as possible. It's not intuitive. It's a pretty common pitfall, but it's logical. For 1-pixel lines it could be fixed by allowing authors to specify that path should be stroked with lines aligned to inside/outside of the path (which is a useful feature on its own). Sure, but how can we fix this? It's not very intuitive that I have to keep track of the devicePixelRatio (and the current CTM?) to get crisp lines. What we need is that artwork 'snaps' to the native pixels while still being antialiased. Illustrator tries to work around this by offering a 'snap to grid' option but users are running into lots of issues (just do a google search for 'illustrator snap to grid')
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
I guess there's too many mights in there :-) I want to adjust line positions and line widths to align edges with device pixels but not the user agent might turn off anti-aliasing for all lines and curves On Tue, Jul 23, 2013 at 6:11 PM, Brian Birtles bbirt...@mozilla.com wrote: (2013/07/24 10:07), Rik Cabanier wrote: yeah, at first blush that seemed what was needed. However, this simply turns off antialiasing completely so regular artwork looks terrible. That's a quality of implementation issue. The description of the property value says, Indicates that the user agent shall attempt to emphasize the contrast between clean edges of artwork over rendering speed and geometric precision. To achieve crisp edges, the user agent might turn off anti-aliasing for all lines and curves or possibly just for straight lines which are close to vertical or horizontal. Also, the user agent might adjust line positions and line widths to align edges with device pixels. I'm not sure what use case you have in mind though. Perhaps it's something that doesn't fit that description?
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
Good memory! I'll dig up that conversation to see what the conclusion was. On Tue, Jul 23, 2013 at 5:18 PM, David Dailey ddai...@zoominternet.netwrote: Hi Rik, Just affirming what you've said in SVG: http://cs.sru.edu/~ddailey/svg/edgeblurs.svg The middle rects are crisp, having been merely translated leftward and downward by half a pixel. Zooming in from the browser rectifies the problem (as expected) after a single tick. I remember folks discussing sub-pixel antialiasing quite a bit on the SVG lists circa fall/winter 2011. It seemed to cause some troubles for D3. Is that the same issue? Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rik Cabanier Sent: Tuesday, July 23, 2013 7:19 PM To: wha...@whatwg.org Subject: [whatwg] Blurry lines in 2D Canvas (and SVG) All, we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, but ideally this should never happen. Is this behavior specified somewhere? Is there a way to turn this off?
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
(The below is about Canvas only; I'm not very familiar with SVG. I think they should be two separate discussions.) On Tue, Jul 23, 2013 at 6:19 PM, Rik Cabanier caban...@gmail.com wrote: we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, For Canvas, you should always add 0.5, since you're in the canvas coordinate space, before the pixel ratio is applied. This is the same coordinate system used by OpenGL and Direct3D 10 (and up), with pixels centered around 0.5x0.5. That is, a pixel sits between 0x0 and 1x1. If you're specifying the center of the line (eg. where the stroke grows outwards from), you need to add a half pixel. (When you're specifying a bounding box, such as drawImage, you don't, since you're at the edge rather than the center of a pixel.) I'm not sure if there's a way to disable antialiasing for paths. Disabling antialiasing to allow people to specify wrong coordinates only seems like it would be more confusing, though. The only solution is to educate people about when and why they need to add a half pixel; even if there was a way to avoid this in general (I'm not sure there is, for an API with Canvas's functionality), it's much too late to change this. -- Glenn Maynard
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
Seeing what Kornel wrote about a solution to the problem for canvas, makes persuasive support, to me, for Glenn Maynard's argument that [concerning SVG and canvas] I think they should be two separate discussions. One of the intentions (at least historically) of SVG is to allow declarative rather than scripted solutions. As I read this conversation from a declarative perspective (trying to transcode script into markup) I am seeing a dozen little flag-attributes that all interact with one another in a grand logical hyperplane. Sorry, for what might be a flawed metaphor, but I've been stuck in a logical hyperplane for the past few days and I am cursing it! Cheers D (Lie algebra is even worse than Lie geometry! -- https://en.wikipedia.org/wiki/Sophus_Lie ) -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Kornel Lesinski Sent: Tuesday, July 23, 2013 10:09 PM To: Rik Cabanier Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Blurry lines in 2D Canvas (and SVG) On Wed, 24 Jul 2013 02:13:19 +0100, Rik Cabanier caban...@gmail.com wrote: It's not intuitive. It's a pretty common pitfall, but it's logical. For 1-pixel lines it could be fixed by allowing authors to specify that path should be stroked with lines aligned to inside/outside of the path (which is a useful feature on its own). Sure, but how can we fix this? It's not very intuitive that I have to keep track of the devicePixelRatio (and the current CTM?) to get crisp lines. To what extent does it need to be fixed? Manually snapping lines to canvas pixels isn't too hard, e.g. subtracting 0.5 from x/y and adding 1 to width/height to get pixel-aligned rectangle outside the box. It does get trickier with transforms indeed :( Is it enough to snap to canvas pixels? (future of HD canvas is uncertain, so authors may need to resize canvas to match devicePixelRatio anyway). Is it enough if there was strokeOutside()/strokeInside() that makes untransformed lines pixel-aligned? Or is it necessary to have snapping for odd-width lines that are stroked centered on a path? Do authors expect lines in canvas with non-integer transforms to be crisp? Should arc() and bezier curves also be snapped? What if you want a line that touches the curve? What we need is that artwork 'snaps' to the native pixels while still being antialiased. How should snapping be done? If fill() of a 2x2 rect draws: XX XX how would stroke() look like? .XX. .XX. or .. .. or ... .X. ... If you have path that is 2.5 device pixels wide, is it going to be snapped to different width depending whether you draw it at (0, 0) or (0.1, 0)? Would that also make circles ellipses? Snapping makes animated slow movement choppy, so authors may also want ability to disable it for selected paths/drawing operations or even for each axis separately (e.g. to smoothly animate horizontal movement while object is snapped to pixels vertically, etc.) -- regards, Kornel
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Tue, Jul 23, 2013 at 6:20 PM, Glenn Maynard gl...@zewt.org wrote: (The below is about Canvas only; I'm not very familiar with SVG. I think they should be two separate discussions.) Agreed. Sorry to confuse the issue. On Tue, Jul 23, 2013 at 6:19 PM, Rik Cabanier caban...@gmail.com wrote: we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, For Canvas, you should always add 0.5, since you're in the canvas coordinate space, before the pixel ratio is applied. That seemed like an OK idea until I thought about it some more. Doing a .5 scale will also affect your fills so a rect will now have aliased borders. Also adjusting for non-round device pixel ratio or as Kornel mentions, having transforms will still result in blurry lines (unless you do a bunch of math) This is the same coordinate system used by OpenGL and Direct3D 10 (and up), with pixels centered around 0.5x0.5. That is, a pixel sits between 0x0 and 1x1. If you're specifying the center of the line (eg. where the stroke grows outwards from), you need to add a half pixel. (When you're specifying a bounding box, such as drawImage, you don't, since you're at the edge rather than the center of a pixel.) I'm not sure if there's a way to disable antialiasing for paths. Disabling antialiasing to allow people to specify wrong coordinates only seems like it would be more confusing, though. Disabling it is not a solution. The 'crispEdges' option does this and the results look bad. The only solution is to educate people about when and why they need to add a half pixel; even if there was a way to avoid this in general (I'm not sure there is, for an API with Canvas's functionality), it's much too late to change this. I agree that we can't change this, but maybe we can add something to make it better. In PDF there is a feature called strokeAdjust that will make the stroke align to pixel boundaries. Basically, if you turn it on strokeAdjust and the stroke doesn't fill the entire pixel, that pixel isn't drawn. If there's less than a pixel total, you expand the stroke to at least a pixel. Apple has a Core Graphics function called CGGStateSetStrokeAdjust so they would be able to implement this easily. :-)
