headers
Justin Novosad | 19 Jun 2013 15:19
Picon
Favicon

Proposal: createImageBitmap should return a "Promise" instead of using a callback

I was about to launch the implementation of window.createImageBitmap in
Blink, and I received feedback on the blink-dev mailing list that the
"Promise" API is the wave of the future for asynchronous JS, and that the
new createImageBitmap method should use Promises.

Current spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#images

The proposal is to change the ImageBitmapFactories IDL to something like
this:

[NoInterfaceObject]
interface ImageBitmapFactories {
  Promise createImageBitmap(ImageBitmapSource image, optional long sx, long
sy, long sw, long sh);
};

The value of the promise would resolve to an ImageBitmap object.

What do we think?
Permalink | Reply | 0 comments |
headers
Rik Cabanier | 14 Jun 2013 20:34
Picon
Gravatar

Re: Grouping in canvas 2d

On Fri, Jun 14, 2013 at 6:04 AM, Brian Salomon <bsalomon@...>wrote:

> As an implementor, we would prefer the layer approach. This would have
> lower overhead in Chromium/Skia. We can make better decisions about caching
> and deferred rendering. It also seems like a really handy API for devs,
> especially the ability to inherit the graphics state. Would the spec have
> anything to say about beginLayer()/endLayer() balancing, especially with
> respect to RAF?
>

I think so. If you leave a layer 'open', what would you display.
It wouldn't just be for requestAnimationFrame, you would also need to
define what happens if you read pixels with getImageData inside a
beginLayer.

>
>
> On Thu, Jun 13, 2013 at 11:57 PM, Rik Cabanier <cabanier@...> wrote:
>
>> Last year, I requested if grouping could be added to canvas.
>> The API would look like this:
>>
>> void beginLayer();
>> void beginLayer(unsigned long x, unsigned long y, unsigned long w,
>> unsigned long h);
>> void endLayer();
>>
>>
>> When you call beginLayer, you inherit everything from the graphics state
>> except shadows, opacity and the current compositing mode. Those will reset
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Hickson | 14 Jun 2013 19:42
Picon

Adding 2D Canvas features (Was: Grouping in canvas 2d)

On Fri, 14 Jun 2013, Brian Salomon wrote:
>
> As an implementor, we would prefer the layer approach. This would have 
> lower overhead in Chromium/Skia. We can make better decisions about 
> caching and deferred rendering. It also seems like a really handy API 
> for devs, especially the ability to inherit the graphics state. Would 
> the spec have anything to say about beginLayer()/endLayer() balancing, 
> especially with respect to RAF?

I have no ojection to adding this to the spec, but right now the spec has 
a bunch of features that aren't implemented, and there's a long list of 
other features people want that aren't yet specced. I'm very hesitant to 
get the spec further and further away from implementations.

For example, here are some of the bug numbers for <canvas> feature 
requests:

11399	<canvas> Locking individual color channels (e.g. drawing to alpha 
                 only)
21835	<canvas> Path object should have a way to add paths keeping only 
                 the union given a fill rule
21939	<canvas> Path objects would be much more useful if their 
                 individual commands (moveTo, lineTo, etc.) could be 
                 inspected from JavaScript [...]
8794	<canvas> lineWidth = 'hairline'
11739	<canvas> clearPath() that clears pixels the way clearRect() does, 
                 but using a path
9236	<canvas> Detecting the intersection of Path objects
9235	<canvas> perspective transformations
18751	<canvas> a way to get the coordinate of the last point in a path
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tetsuharu OHZEKI | 14 Jun 2013 14:25
Picon
Gravatar

How works Promise.any() if it was called with resolved promises?

Hello,

I have questions about DOM Promise.

If we call `Promises.any()` with resolved promises, how does it
execute its fulfillCallback?

The following is sample code:
```
var p1 = new Promise(function(r){
  r = r.resolve("value1");
});
var p2 = new Promise(function(r){
  r = r.resolve("value2");
});
var p3 = new Promise(function(r){
  r = r.resolve("value3");
});

// Pass some promises which have been resolved already.
Promsie.any(p1, p2, p3).then(function(){
  // how will the browser call this function?
});

```

Thank you.

--
Tetsuharu OHZEKI
(Continue reading)

Permalink | Reply | 6 comments |
headers
Rik Cabanier | 14 Jun 2013 05:57
Picon
Gravatar

Grouping in canvas 2d

Last year, I requested if grouping could be added to canvas.
The API would look like this:

void beginLayer();
void beginLayer(unsigned long x, unsigned long y, unsigned long w, unsigned
long h);
void endLayer();

When you call beginLayer, you inherit everything from the graphics state
except shadows, opacity and the current compositing mode. Those will reset
to their initial value.
At endLayer time, the graphics state will be restored and you will draw the
content of the group.

so for instance, if you want multiply blend with opacity of .5

ctx.globalAlpha = .5;
ctx.globalCompositeOperation = "multiply";
ctx.beginLayer();
... // drawing
ctx.endLayer();

This would cause everything between begin/endLayer to be drawn normally.
This result is then blended and composited at endLayer time.

Last year, people argued that you could achieve the same effect by using a
temporary canvas so this API is not really needed.
I would like to see if people are more open to this API now.
Reasons to have it:
- it is easily achievable with existing graphics libraries.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Silvia Pfeiffer | 12 Jun 2013 07:11
Picon
Gravatar

Reconsidering how we deal with text track cues

Hi all,

The model in which we have looked at text tracks (<track> element of
media elements) thus far has some issues that I would like to point
out in this email and I would like to suggest a new way to look at
tracks. This will result in changes to the HTML and WebVTT specs and
has an influence on others specifying text track cue formats, so I am
sharing this information widely.

Current situation
=============
Text tracks provide lists of timed cues for media elements, i.e. they
have a start time, an end time, and some content that is to be
interpreted in sync with the media element's timeline.

WebVTT is the file format that we chose to define as a serialisation
for the cues (just like audio files serialize audio samples/frames and
video files serialize video frames).

The means in which we currently parse WebVTT files into JS objects has
us create objects of type WebVTTCue. These objects contain information
about any kind of cue that could be included in a WebVTT file -
captions, subtitles, descriptions, chapters, metadata and whatnot.

The WebVTTCue object looks like this:

enum AutoKeyword { "auto" };
[Constructor(double startTime, double endTime, DOMString text)]
interface WebVTTCue : TextTrackCue {
           attribute DOMString vertical;
(Continue reading)

Permalink | Reply | 5 comments |
headers
Albert Bodenhamer | 11 Jun 2013 23:46

Proposal:Improve internationalization in the autocomplete attribute

Lara Rennie (CCed) and I have been looking over the autocomplete
attribute<http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete>over
the past week with an eye towards better i18n.  We'd like to propose a
few changes.

Some are covered in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22286.
 The rest I'll address here.

Address lines:
Currently: Recommended handling for addresses is currently as a single
line.  Alternatively, sites can ask for address lines 1-3 but this is
discouraged.
Problem: Single line doesn't work well for all regions. Some areas have 5
lines for an address and might have more.
Proposal: If address is requested as a single line newlines should be
preserved when filling. Stop discouraging the use of address-lines. Support
more than 3 lines for address.  Potentially, address-lineX where X can be
1-9.

Address 'locality':
Problem: Some regions have the concept of a "post town".  It's currently
unclear how this should be requested.
Proposal: Add "post town" to the list of expected localities in the
description to make it more clear how this should be requested.

Address CEDEX codes:
Problem: They don't fit well into the "postal-code" field and are often
handled as a separate entity.
Proposal: Add a field name for CEDEX code.
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Flanagan | 7 Jun 2013 22:42

Add EXIF metadata support in Canvas.toBlob?

If the second argument to Canvas.toBlob() and Canvas.toBlobHD() is 
"image/jpeg", then these methods support a third argument to specify 
JPEG compression level.

The spec

(http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#a-serialization-of-the-bitmap-as-a-file) 
says:
> A future version of this specification will probably define other 
> parameters to be passed to these methods to allow authors to more 
> carefully control compression settings, image metadata, etc.
I would like to propose the addition of a fourth argument (for the JPEG 
case only) that would specify EXIF metadata to be included in the JPEG 
blob.  (I have not tried yet, but I'm assuming that we could define some 
suitable JSON serialization format for EXIF data. If not, then even 
allowing a binary blob of EXIF data as the fourth argument would be 
helpful.)

The use case for this feature is image editing applications, like the 
Gallery app on FirefoxOS devices. Whenever that app crops or edits a 
photo it encodes the edited photo with Canvas.toBlob(), and the process 
strips all metadata from the photo.  Reading EXIF data from a JPEG blob 
is relatively straightforward can can be done with JavaScript, but 
inserting EXIF data into an existing blob is much harder: this is a task 
that is best done when the JPEG blob is being created, which means that 
it is a feature that belongs in toBlob and can not be done efficiently 
with an external library.

[A related, but perhaps too ambitious, proposal is to allow direct 
read/write access to EXIF metadata via HTMLImageElement.  The primary
(Continue reading)

Permalink | Reply | 5 comments |
headers
Peter Occil | 6 Jun 2013 11:42
Picon
Gravatar

[mimesniff] More issues on the MIME Sniffing spec

I want to respond to the following issues in the MIME Sniffing spec:

Resources

I suggest the following wording for the issue box starting with "A resource is..."

   A resource is a data item or message, such as a file or an HTTP response.

I believe this covers the cases that would normally be associated with a MIME type.

Contexts

I don't think the word "context" needs to be specially defined.  The start of section 8
could be rewritten to remove the definition:

[[
In certain cases, it is only useful to identify resources that belong to a certain subset of MIME types. In
these cases, it is appropriate to use a context-specific sniffing algorithm in place of the MIME type
sniffing algorithm in order to determine the sniffed MIME type of a resource. 

This specification defines the following context-specific sniffing algorithms.
]]

Apache Bug

As for the Apache bug flag, would it be useful to additionally check the HTTP 
headers for a Server header and check if it contains "Apache/"?  I don't know which
version of Apache the bug involved was fixed in, so I can't suggest a more accurate
string check.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rodrigo Polo | 4 Jun 2013 12:25
Picon
Gravatar

Request: Implementing a Geo Location URI Scheme

Many apps and web browsers make very difficult to work around geo location
data, making a URI scheme available in all web browsers could be great,
just like "mailto:" opens an email client "geo:" could open your default
maps app on desktop or mobile devices, here I give you a more detailed
review, an open letter to all web browser devs: http://rod.gs/fixgeo

--

-- 
Rodrigo J. Polo
www.rodrigopolo.com
Permalink | Reply | 12 comments |
headers
Rodrigo Polo | 4 Jun 2013 12:23
Picon
Gravatar

Request: Implementing a Geo Location URI Scheme

Many apps and web browsers make very difficult to work around geo location
data, making a URI scheme available in all web browsers could be great,
just like "mailto:" opens an email client "geo:" could open your default
maps app on desktop or mobile devices, here I give you a more detailed
review, an open letter to all web browser devs: http://rod.gs/fixgeo

--

-- 
Rodrigo J. Polo
www.rodrigopolo.com
Permalink | Reply | 0 comments |

Gmane