Re: API for matrix manipulation

[Lars Knudsen]

Hi,

related to this:  Is there any work ongoing to tie these (or more generic
vector / matrix) classes to OpenCL / WebCL for faster computation across
CPUs and GPUs?

- Lars

On Mon, Mar 14, 2011 at 5:17 PM, Chris Marrin  wrote:

>
> On Mar 14, 2011, at 7:56 AM, João Eiras wrote:
>
> Hi.
>
> Given that a number of API are being developed that require complex
> matricial calculations (transforms, device orientation, web gl), I
> would suggest that perhaps an API with a big number of common
> calculations could be made available ? And a proper way to represent
> them. Perhaps, the best way to add this would be to extend the Math
> object with things like.
>
> Math.mAdd(m1, m2)
> Math.mSub(m1, m2)
> Math.mMult(m1, m2)
> Math.mDiv(m1, m2)
> Math.mInverse(m1)
> Math.mGaussianReduce(m1)
> Math.mRank(m1)
> Math.mRank(m1)
>
> Being the matrix an array like object like (could even be one of those
> fast arrays like ArrayBuffer).
>
> # {
> #  w: ,
> #  h: ,
> #  length: 
> #  0: ...,
> #  1: ...,
> #  2: ...
> #  (...)
> # }
>
> Comments or is something already being worked on ?
>
>
> There are already 2 such classes: SVGMatrix and CSSMatrix. The former is an
> affine transformation matrix (commonly misnamed a "2x3 matrix") and the
> latter is a 3D homogeneous transformation matrix (commonly correctly named a
> "4x4 matrix").
>
> We added CSSMatrix to the CSS Transform Spec to give us the same
> functionality as SVG Matrix, but for 3D transforms. Therefore both of these
> classes are pretty light on their operators. It might be useful to discuss
> "one matrix to rule them all", which could be used in place of the current
> classes and with more functionality. But it's important not to go too far
> down this path, or you'll end up defining classes for Points, Lines, Planes,
> Bounding Boxes and View Volumes with dozens of functions. Down that path
> lies madness.
>
> I think the current spec handles the more complex (inverse and multiply)
> and more commonly used (scale, rotate, translate) functions. I'm not sure
> what adding and subtracting 2 matrices means, and division is handled by
> inverse and multiply. The others seem pretty domain specific for a general
> class. And remember you can (and many people have) created JS libraries to
> add funcrtions to the built-in matrix classes. I wrote one:
>
>
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/webkit/resources/J3DIMath.js
>
> which uses CSSMatrix if it exists and uses JS otherwise. It exposed some
> interesting deficiencies in the current CSSMatrix class. There are several
> bugs on WebKit to address these and other issues of matrix efficiency and
> functionality: 23799 ,
> 28850 , 
> 50633
> , 52488 . Perhaps it would
> be useful to open these (or similar) bugs on the w3c bug system?
>
> That's where I believe we are on the Matrix front.
>
> -
> ~Chris
> cmar...@apple.com
>
>
>
>
>

Re: [screen-orient] Updated editor draft

[Lars Knudsen]

Why not use the existing definitions in the orientation change event?

http://developer.apple.com/library/ios/#documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#//apple_ref/doc/uid/TP40006511-SW16

simple "landscape" and "portrait" can always be deducted from the values -
but you have more precise info.  This is also possible to map to/from
accelerometer data if needed.

(speaking as a web demos/apps/games developer).

code quote:

switch(window.orientation)
{
case 0:
displayStr += "Portrait";
break;

case -90:
displayStr += "Landscape (right, screen turned
clockwise)";
break;

case 90:
displayStr += "Landscape (left, screen turned
counterclockwise)";
break;

case 180:
displayStr += "Portrait (upside-down portrait)";
break;

}

br
Lars


On Mon, Nov 5, 2012 at 4:54 PM, Mounir Lamouri  wrote:

> Hi,
>
> I've just pushed a new editor draft [1] with some cosmetic/editorial
> changes and a new feature: lockOrientation() can now be called with a
> sequence to lock the screen to different orientations (for
> example, "portrait-primary" and "landscape-primary").
>
> Any feedback is welcome!
>
> Note that I will update the WD in about a week if I do not hear anything
> in the meantime.
>
> [1] http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html
>
> Thanks,
> --
> Mounir
>
>

Re: The need to re-subscribe to requestAnimationFrame

[Lars Knudsen]

Without having used it too much, I'd say it is because of the following:

Imagine that you have a callback that does a lot of heavy rendering and the
rAF returns AGAIN while "// do stuff".  Then you'd all of a sudden have an
accumulating list of "do stuff'ers" that run in parallel - eating away CPU.

There is no need to ask for the next available "paint slot" until the
previous work is cleared out of the way.

Correct me if I am wrong.

- Lars


On Sat, Mar 2, 2013 at 12:03 PM, David Bruant  wrote:

> Hi,
>
> If someone wants to reuse the same function for requestionAnimationFrame,
> he/she has to go through:
> requestAnimationFrame(function f(){
> requestAnimationFrame(f);
> // do stuff
> })
>
> I was wondering why it was the case. Other event-like mechanism do not
> require to re-subscribe after an event happened.
>
> Thanks,
>
> David
>
>

Re: Screen Orientation API: Feedback

[Lars Knudsen]

Hi,

Having some background in both webapps and actual browser development
(webkit, Nokia N9), I see a few issues with the current proposal (some
already mentioned in the mozilla thread about this last year).

1. whatever terminology chosen for portrait/landscape and primary/secondary
it NEEDS to be aligned with the media queries terminology AND values or
every web developer will have to somehow make their own mapping to handle
things.

2. IMO, one of the primary reasons for having orientation lock is to be
able to (finally) do proper accelerometer (DeviceOrientation) based games.
 For this to work smoothly for the developers, the axis orientation NEED to
be aligned with the orientation.

Application developers are usually not stupid - but do many mistakes and
need to test and develop workarounds for a load of different devices if the
specs are not aligned and the values are not consistent.

PLEASE (seriously) consider not letting the device manufacturer decide what
is the "natural 0 degree" - but require that DEG_0 = PORTRAIT_UP = (0,1,0)

As i mention above - it's MUCH easier for game developers to figure out
that they need to do a 90 degree mapping of everything if they choose to do
a landscape locked game than somehow handling weird translations in some of
the cases (with devices they might not even have access to).

In any case, any spec should be smoke tested on real developers before
going out of draft :)

br
Lars Knudsen


On Sun, Apr 7, 2013 at 6:33 AM, Anne van Kesteren  wrote:

> This is feedback for the draft located at
> https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html
>
> 1) Per http://dev.w3.org/csswg/cssom-view/ Screen does not inherit
> from EventTarget so dispatching events to it will not give you
> anything meaningful. That should be fixed one way or another.
>
> 2) Rather than using sequence, the preferred way for creating an API
> that takes a list is using a variadic:
>
>   boolean lockOrientation(DOMString... orientations);
>
> 3) The algorithms end up dispatching events, however no task is
> queued. That's a bug.
>
> 4) Rather than using DOMString, an enum should be used. This should
> also simplify the algorithms somewhat (though beware that by using a
> variadic no argument passed is a possibility).
>
> 5) An event handler attribute IDL definition should not have
> "[TreatNonCallableAsNull]".
>
>
> --
> http://annevankesteren.nl/
>
>

Re: Screen Orientation API: Feedback

[Lars Knudsen]

On Tue, Apr 9, 2013 at 4:01 PM, Jonas Sicking  wrote:

> On Sun, Apr 7, 2013 at 10:44 AM, Lars Knudsen  wrote:
> > Hi,
> >
> > Having some background in both webapps and actual browser development
> > (webkit, Nokia N9), I see a few issues with the current proposal (some
> > already mentioned in the mozilla thread about this last year).
> >
> > 1. whatever terminology chosen for portrait/landscape and
> primary/secondary
> > it NEEDS to be aligned with the media queries terminology AND values or
> > every web developer will have to somehow make their own mapping to handle
> > things.
>
> I agree that we should align with media queries.
>
> > 2. IMO, one of the primary reasons for having orientation lock is to be
> able
> > to (finally) do proper accelerometer (DeviceOrientation) based games.
>  For
> > this to work smoothly for the developers, the axis orientation NEED to be
> > aligned with the orientation.
>
> I think that the direction that per DeviceOrientation is "up" is
> what's *rendered* as "up" and not what's "up" on the hardware. That
> way the only difference between a page that's locked in landscape mode
> vs. portrait mode is the dimentions of the window, and not the
> coordinates that you receive from the deviceorientation events.
>

As long as both MediaQueries, xyz-accelerometer data, orientation lock and
more *all* are aligned, this could work.
However, we need to have this tested with a bunch of developers - to see
where they make mistakes caused by possible confusion.

My own opinion on this is still to keep it in a specific orientation also
(e.g. "portrait up") as 0 degrees, as it makes everything more easy to
handle
when the basics are kept static.  I can tell you that even inside the same
company (mobile phone manufacturer), I have seen mistakes in the mapping
of the xyz-accelerometer values *alone* between units coming from slightly
different branches.  This was because some were "landscape" devices
and some were "portrait" and everything have to match from the low level HW
to the high level javascript API.

If we make sure that a device - no matter how the rest of the UI is turning
- is always considered "0 degrees" when held - e.g. "portrait up", (x,y,z)
= (0,1,0), then:

1. non-game developers can be happy with "lock to landscape" and never need
to worry about the inner workings  and
2. game developers (using the accelerometer) won't have to reinvent strange
mappings when juggling media queries, accelerometer and orientation lock.

If we allow "natural landscape" units and "natural portrait" units - then
in some cases, when in a landscape locked game, the gravity goes in the
direction of "negative X" - and in some cases it goes in the direction of
"negative Y".  And it gets worse if you don't even know which landscape
(left or right up) you got.

If we enforce that the device always has "0 degrees" when held portrait up
(Y positive pointing at 90 degrees) - then "lock to landscape right up"
always gives gravity in "negative X".



>
> This definitely needs to be defined somewhere.
>
> / Jonas
>

- Lars

Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?

[Lars Knudsen]

On Wed, Apr 24, 2013 at 1:00 PM, Kenneth Rohde Christiansen <
kenneth.r.christian...@intel.com> wrote:

> Hi there,
>
> CSS Device Adaptation should hopefully be enabled on all browsers (desktop
> and mobile) unlike the viewport meta tag, which cannot be enabled on
> desktop browsers easily as many desktop sites actually comes with a
> viewport meta tag which is ignored. Having that not being ignored breaks
> the sites.
>
> MS already enabled a subset of the CSS Device Adaptation spec in IE10
> desktop.
>
> I support adding some CSSOM API's for CSS Device Adaptation, but I would
> not do so for the viewport meta tag, which has its share of issues. I would
> also like the CSS Device Adaptation, orientation lock and Fullscreen to
> integrate. Especially it would be nice to click on an element in portrait
> and have it go fullscreen in landscape mode and lock, all with a nice
> animation.
>

IMO, this would be a much more clean and easy to understand solution than
providing a separate API for orientation lock.  It would also remove 1
"unknown" element when game developers try to juggle mappings between
xyz-accelerometer data vs media query orientation vs "device normal
orientation" (as some propose to have "natural landscape" and "natural
portrait" devices - something I really think would just add to the
confusion).

Allow me to quote myself from an earlier other thread on a proposed
orientation lock API:

"
As long as both MediaQueries, xyz-accelerometer data, orientation lock and
more *all* are aligned, this could work.
However, we need to have this tested with a bunch of developers - to see
where they make mistakes caused by possible confusion.

My own opinion on this is still to keep it in a specific orientation also
(e.g. "portrait up") as 0 degrees, as it makes everything more easy to
handle
when the basics are kept static.  I can tell you that even inside the same
company (mobile phone manufacturer), I have seen mistakes in the mapping
of the xyz-accelerometer values *alone* between units coming from slightly
different branches.  This was because some were "landscape" devices
and some were "portrait" and everything have to match from the low level HW
to the high level javascript API.

If we make sure that a device - no matter how the rest of the UI is turning
- is always considered "0 degrees" when held - e.g. "portrait up", (x,y,z)
= (0,1,0), then:

1. non-game developers can be happy with "lock to landscape" and never need
to worry about the inner workings  and
2. game developers (using the accelerometer) won't have to reinvent strange
mappings when juggling media queries, accelerometer and orientation lock.

If we allow "natural landscape" units and "natural portrait" units - then
in some cases, when in a landscape locked game, the gravity goes in the
direction of "negative X" - and in some cases it goes in the direction of
"negative Y".  And it gets worse if you don't even know which landscape
(left or right up) you got.

If we enforce that the device always has "0 degrees" when held portrait up
(Y positive pointing at 90 degrees) - then "lock to landscape right up"
always gives gravity in "negative X".

"

The problem might sound like a small one - but as a web game developer, I
would MUCH rather develop for devices, where I know that "in my
landscape-left game, natural UP is X+" than being forced to buy and test on
all thinkable devices out there because the spec allows for manufacturers
to have "natural landscape" units, where "full screen portrait" could
be anything (really) when mapping the xyz accelerometer data to my game.


br
Lars



>
> Cheers
> Kenneth
>
>
>
> On Wed, Apr 24, 2013 at 12:13 PM, Tobie Langel  wrote:
>
>> Hi,
>>
>> Screen orientation lock is critical to a whole set of mobile games
>> (especially those which rely on the accelerometer to control the gameplay).
>> It's great that it is now considered for specification and implementation.
>>
>> I had collected some use cases a while back[1], some of which led to
>> use-cases[2], requirements[3] and suggestions[4] in the Coremob report.
>>
>> While some of the original use cases required dynamically modifying
>> orientation lock (e.g. the Game within a game experience[5]), key use cases
>> simply require a declarative, page-wide setting, as described by David
>> Bruant on the WHAT WG mailing list[6].
>>
>> The current proposal[7] only targets the dynamic setting through a JS API
>> and leaves the more declarative approach to other specs[8]. It mentions the
>> Web Application Manifest Format and Management APIs[9] and CSS Device
>> Adaptation[10].
>>
>> Now, CSS Device Adaptation, as used in the Viewport META element[11] is
>> ubiquitous on mobile. It seems like a natural fit for a declarative
>> orientation lock, so much so that it's already specified in the spec[12].
>>
>> However, the syntax to dynamically read or modify the Viewport META
>> element is cumbersome and error prone (you're talking document.cookie-like
>> string s

Re: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation

[Lars Knudsen]

Hi,

I know, I've mentioned this before - but why don't we just define one
(hardware) direction as "0 degrees" (e.g. "portrait up"), align all the
orientation specs and keep things simple for everyone?

ref
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0063.html


br
Lars





On Fri, Aug 16, 2013 at 5:03 AM, Jonas Sicking  wrote:

>
> On Aug 15, 2013 5:11 PM, "Dhruv Chadha" 
> wrote:
> >
> > Tab,
> >
> > We sympathize with the goal of creating a simple programming model for
> developers but we don’t believe that is what is currently specified on the
> device and screen orientation specs (as we stated in our earlier response
> to Jonas).  Our proposal maps existing native implementations done by iOS,
> Android, and Windows.  These native APIs provide capabilities to discover
> the native orientation of the device and to remap the coordinate system
> based on the user selected orientation.
> >
> > We believe that mapping the coordinates to the current screen
> orientation would generate the following issues:
> > - Changes the design of the API as defined by current draft of the
> device orientation spec and will break interoperability with current
> implementations
>
> I agree this is a problem.
>
> > - If the browser’s orientation is not locked, rotating the device would
> reset the coordinates back to 0 in the reference axis for each 90 degree
> rotation since the browser App UI would rotate as well
>
> Why is this bad? Maybe I'm not understanding the concern?
>
> > - Does not provide flexibility.  What happens if the developer is not
> interested in automatically re-mapping the coordinate system?  They
> wouldn’t have an ability to change this behavior.
>
> What are the use cases for wanting to allow the screen to reorient while
> at the same time not adjusting the coordinate system? Are these use cases
> more common than the cases where you would want to adjust the coordinate
> system?
>
> A potential solution is to add a separate set of events exactly like the
> current DeviceOrientation events, but that are relative to the screen
> orientation rather than the device orientation. Sadly that might be the
> only way to keep compatibility with existing deployed implementations,
> while still keeping a decent API.
>
> > - the alpha value (+Z) for device orientation should always be aligned
> to the input from the compass (i.e. hardware sensors) unless the developer
> requests a re-mapping
>
> I don't understand this. Could you provide an example or describe in more
> detail?
>
> / Jonas
>

Re: Define window.orientation

[Lars Knudsen]

True Kenneth,

- but in all cases, it would be good if anything related to orientation
(Media Query, accelerometer, etc.) at least had a common holistic way of
defining "what is up" ~ (x,y,z) = (0,1,0) or so . and if that *changes* if
the different levels of orientation (device lock, window, etc.) somehow
auto-rotates on device rotate or it follows the HW accelerometer and
couldn't care less about pixels on screen.  Someone should - seriously - be
the "holistic owner of all things orientation for Web".

- Lars


On Tue, Nov 5, 2013 at 12:23 PM, Kenneth Rohde Christiansen <
kenneth.christian...@gmail.com> wrote:

> They are somewheat different things. The former is basically a way to get
> accelerometer info (useful for games etc) and the latter is about actual
> OS(/Screen) orientation, in which the window.orientation (Browser
> orientation) falls.
>
> Kenneth
>
>
> On Tue, Nov 5, 2013 at 12:03 PM, Anne van Kesteren wrote:
>
>> It seems either http://dev.w3.org/geo/api/spec-source-orientation.html
>> or https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html
>> needs to define and standardize the proprietary window.orientation
>> feature because not having it defined is a problem:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=920342
>>
>> As an aside, any chance we could have those two drafts be a single
>> draft covering that whole spectrum?
>>
>>
>> --
>> http://annevankesteren.nl/
>>
>>
>
>
> --
> Kenneth Rohde Christiansen
> Web Platform Architect, Intel Corporation.
> Phone  +45 4294 9458 ﹆﹆﹆
>

Re: [screen-orientation] screen orientation angle

[Lars Knudsen]

+1 to this new angle ;)

Seriously, it would be great if we can finally get closer to a solution
where (especially) new web apps developers will not get too confused about
different representations of orientation between different specs and
devices.  It would be great with some reference apps to hold this up
against while the spec is still possible to change.  If anyone feels it
makes sense, I'd be happy to chip in with that.

One thing that is not 100% clear to me if handled yet though:  IMO, it
 would make sense to agree on portrait or landscape to be *the* primary
orientation for all devices - and let everything else be a relative angle
(in degrees) to that.  Most cases where developers will need this feature
will be for games utilizing the accelerometer (xyz readings) AND they will
most likely design the game for portrait or landscape use.  Not having to
deal with differences between landscape/portrait devices but just be able
to rely on "(X,Y,Z) = (0,1,0)" when holding the device "portrait up" in all
cases will eliminate one layer of mapping.  If this is already handled
here, I am sorry for repeating myself.

best wishes
Lars



On Tue, Nov 26, 2013 at 9:25 AM, John Mellor  wrote:

> This all sounds reasonable; it's great that we'll be able to remove the
> spec's artificial requirement that "if the device is in landscape-primary
> and is rotated 90 degrees clockwise, that should be represented as
> portrait-primary".
>
> And it potentially opens the door to using a less error-prone selection of
> keywords too.
>
>
> On Tue, Nov 26, 2013 at 4:38 PM, Mounir Lamouri  wrote:
>
>> Hi,
>>
>> The Screen Orientation API defines an angle relationship between
>> portrait-primary and landscape-primary. The reason for that is that
>> developers would know which orientation is at 90 degrees from the
>> current orientation, which one is at 180 degrees, etc. However, by
>> forcing the two primary orientations to have a relationship, we prevent
>> UA to do clever things like having landscape-primary being related to
>> how the user uses his phone (eg. usually depending on which hand is
>> used, the most common landscape is not going to be different).
>>
>> In addition, some use cases might need to know the angle between the
>> current orientation and the native device orientation. For example, a
>> compass using DeviceOrientation would need to know this angle to be able
>> to draw the correct information on the screen [1].
>>
>> This is also a UC that Mozilla has with Firefox OS where some apps want
>> to lock the orientation to the native device orientation (ie. angle=0)
>> [2].
>>
>> So, the Screen Orientation API should allow locking to a specific
>> orientation angle. For that, we could allow an integer to be passed to
>> the lockOrientation() function, a modulo operation would be applied on
>> the number to have it in the [0; 360[ range. If the UA is not able to
>> lock to the specified angle, the method should fail (return false for
>> the moment, the promise should fail in the future).
>>
>> The orientation angle should also be read. It would be possible to
>> simply use window.orientation. I am not a big fan of that solution [3]
>> but this is implemented by most Mobile UAs already so it might as well
>> be the best thing to do. An alternative would be to have something like
>> screen.orientationAngle or screen.orientation.angle (and
>> screen.orientation.name).
>>
>> WDYT?
>>
>> [1] http://oldworld.fr/google/compass.html
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=908058
>> [3] the value can be negative, which is a footgun and the having this
>> value living in window and the rest in window.screen is odd
>>
>> --
>> Mounir
>>
>>
>

Re: Screen Orientation API Spec (from phrasing confusion)

[Lars Knudsen]

What happened to the initiative done to take a holistic view on all
orientation related specs and make them seem like they come from the same
entity (Device Motion, Media Queries, Orientation Lock, ...)?

The confusion grows when we have e.g. different "primary" orientations
(landscape, portrait) - we had similar problems even inside a big handset
manufacturer, I worked with some years ago... within the same company but
in different branches.  How can we then expect avg joe developers out there
to know how to make their app support all devices on this little simple
thing?

IMHO - please include different (hands on) developers on different levels
to try out a spec before it goes out of draft.

br
Lars


On Thu, Mar 13, 2014 at 11:22 PM, Bruno Racineux  wrote:

>
> On 3/13/14 10:59 AM, "Mounir Lamouri"  wrote:
>
> >> http://msdn.microsoft.com/en-us/library/ie/dn433241(v=vs.85).aspx
> >>
> >> That seems to defeat the "normal orientation" aspect of the spec and the
> >> usefulness of '-primary' and '-secondary' suffixes "for the initial
> >> state".
> >
> >There is a bug on file to make the explanation a bit clearer:
> >https://www.w3.org/Bugs/Public/show_bug.cgi?id=24699
>
> I don't think you are getting my initial point of confusion in the spec.
> This would make it even more confusing than it already is.
>
> >The relation between -primary and -secondary should be up to the UA.
>
> You mean the *device* not the UA? Or else you are puzzling me.
> The spec said/says: "The concepts of primary orientation and secondary
> orientation depends on the device and the platform"; *not* the browser.
> Or is there a private draft I can't see saying the contrary now?
>
> >If Microsoft wants to give specific angles, why not.
>
> OK now you are *completely* losing me. Why not? What the heck do you mean?
> The current specification *has* a 90 degrees clockwise given angle which
> Microsoft *followed*.
>
> I have the feeling that neither Mozilla or Microsoft were able
> to fully make sense of the spec as you express it here, which as I
> specified, isn't fully understandable on its own terms.
>
> Again, in 3.1: "In both if the device is in landscape-primary and is
> rotated 90 degrees clockwise, that should be represented as
> portrait-primary." You are giving an angle, while referring to 'In both'
> of 2 previous opposite cases. That sentence is deprived of logic with:
> [In both] !== [if the device is in landscape-primary] in the same sentence.
>
> Microsoft's interpretation of that sentence is:
> [In both if the device is in x-primary and is rotated 90 degrees
> clockwise, that should be represented as x-primary.]
> As such Microsoft would be on spec but that's not what the spec says.
>
> While Mozilla seems to map it to fixed angles as per:
> http://mxr.mozilla.org/mozilla-central/source/widget/gonk/OrientationObserv
> er.cpp
>
> static OrientationMapping sOrientationMappings[] = {
>   {nsIScreen::ROTATION_0_DEG,   eScreenOrientation_PortraitPrimary},
>   {nsIScreen::ROTATION_180_DEG, eScreenOrientation_PortraitSecondary},
>   {nsIScreen::ROTATION_90_DEG,  eScreenOrientation_LandscapePrimary},
>   {nsIScreen::ROTATION_270_DEG, eScreenOrientation_LandscapeSecondary},
> };
>
> which sigh, doesn't match with my initial js implemention based on
> Microsoft's spec. That's a discrepancies already between the two
> prefixed implementations.
>
> I don't know how Tizen is interpreting the spec, but this need to be
> clarified before UAs ship it a unprefixed with their own take on it.
> Or this API is looking live a future living hell for developers.
>
> -Bruno
>
>
>
>

Re: Proposal Virtual Reality "View Lock" Spec

[Lars Knudsen]

I think it could make sense to put stuff like this as an extension on top
of WebGL and WebAudio as they are the only two current APIs close enough to
the bare metal/low latency/high performance to get a decent experience.
 Also - I seem to remember that some earlier generation VR glasses solved
the game support problem by providing their own GL and Joystick drivers
(today - probably device orientation events) so many games didn't have to
bother (too much) with the integration.

In theory - we could:

 - extend (if needed at all) WebGL to provide stereo vision
 - hook up WebAudio as is (as it supports audio objects, Doppler effect,
etc. similar to OpenAL
 - hook up DeviceOrientation/Motion in Desktop browsers if a WiiMote, HMD
or other is connected
 - hook up getUserMedia as is to the potential VR camera

..and make it possible to do low latency paths/hooks between them if needed.

It seems that all (or at least most) of the components are already present
- but proper hooks need to be made for desktop browsers at least (afaik ..
it's been a while ;))

- Lars


On Wed, Mar 26, 2014 at 7:18 PM, Brandon Jones  wrote:

> So there's a few things to consider regarding this. For one, I think your
> ViewEvent structure would need to look more like this:
>
> interface ViewEvent : UIEvent {
> readonly attribute Quaternion orientation; // Where Quaternion is 4
> floats. Prevents gimble lock.
> readonly attribute float offsetX; // offset X from the calibrated
> center 0 in millimeters
> readonly attribute float offsetY; // offset Y from the calibrated
> center 0 in millimeters
> readonly attribute float offsetZ; // offset Z from the calibrated
> center 0 in millimeters
> readonly attribute float accelerationX; // Acceleration along X axis
> in m/s^2
> readonly attribute float accelerationY; // Acceleration along Y axis
> in m/s^2
> readonly attribute float accelerationZ; // Acceleration along Z axis
> in m/s^2
> }
>
> You have to deal with explicit units for a case like this and not
> clamped/normalized values. What would a normalized offset of 1.0 mean? Am I
> slightly off center? At the other end of the room? It's meaningless without
> a frame of reference. Same goes for acceleration. You can argue that you
> can normalize to 1.0 == 9.8 m/s^2 but the accelerometers will happily
> report values outside that range, and at that point you might as well just
> report in a standard unit.
>
> As for things like eye position and such, you'd want to query that
> separately (no sense in sending it with every device), along with other
> information about the device capabilities (Screen resolution, FOV, Lens
> distortion factors, etc, etc.) And you'll want to account for the scenario
> where there are more than one device connected to the browser.
>
> Also, if this is going to be a high quality experience you'll want to be
> able to target rendering to the HMD directly and not rely on OS mirroring
> to render the image. This is a can of worms in and of itself: How do you
> reference the display? Can you manipulate a DOM tree on it, or is it
> limited to WebGL/Canvas2D? If you can render HTML there how do the
> appropriate distortions get applied, and how do things like depth get
> communicated? Does this new rendering surface share the same Javascript
> scope as the page that launched it? If the HMD refreshes at 90hz and your
> monitor refreshes at 60hz, when does requestAnimationFrame fire? These
> are not simple questions, and need to be considered carefully to make sure
> that any resulting API is useful.
>
> Finally, it's worth considering that for a VR experience to be effective
> it needs to be pretty low latency. Put bluntly: Browser suck at this.
> Optimizing for scrolling large pages of flat content, text, and images is
> very different from optimizing for realtime, super low latency I/O. If you
> were to take an Oculus Rift and plug it into one of the existing
> browser/Rift demos  with
> Chrome, you'll probably find that in the best case the rendering lags
> behind your head movement by about 4 frames. Even if your code is rendering
> at a consistent 60hz that means you're seeing ~67ms of lag, which will
> result in a motion-sickness-inducing "swimming" effect where the world is
> constantly catching up to your head position. And that's not even taking
> into account the question of how well Javascript/WebGL can keep up with
> rendering two high resolution views of a moderately complex scene,
> something that even modern gaming PCs can struggle with.
>
> That's an awful lot of work for technology that, right now, does not have
> a large user base and for which the standards and conventions are still
> being defined. I think that you'll have a hard time drumming up support for
> such an API until the technology becomes a little more widespread.
>
> (Disclaimer: I'm very enthusiastic about current VR research. If I sound
> negative it's because I'm

Re: Screen Orientation Status

[Lars Knudsen]

Hi,

It looks better that we now finally have angles in the spec - but I still
don't see any direct link to how the X and Y axis should be mapped against
devices with "portrait primary" and "landscape primary" as their natural
"up" (terms that I as a web application developer still don't find very
useful - sorry).  Again - what happened to the initiative to take a
holistic view on DeviceOrientation, Media Queries and orientation lock all
together?

Not addressing these things will give real everyday issues when
manufacturers and developers both will mess up the mappings - what works on
one device will work opposite on the next.  As late as today, when trying
out the crosswalk framework, we realized that the mappings for landscape vs
XY-axis directions were opposite of what we have on the N9 and iPhone and
again differently mapped when running the exact same thing on a tablet with
"landscape primary" as "up" ... seriously... how many real developers have
been involved in making this spec? (I know I am starting to sound a bit
rude - but I am also tired of being ignored for 3 years on the topic).

Keep it simple:

"portrait up" = "global up" = "(x,y,z) = (0,1,0)" and everything else can
be mapped by even the worst app developer by trial and error .. if that's
what it takes.  No magic - no need to buy a range of devices to test on.

br
Lars (ex-Nokian/part of MeeGo N9/WK2 team)



On Fri, Apr 4, 2014 at 1:01 PM, Arthur Barstow wrote:

> On 4/3/14 11:24 PM, ext Marcos Caceres wrote:
>
>> On April 3, 2014 at 4:38:41 PM, Mounir Lamouri (mou...@lamouri.fr) wrote:
>>
>>> Test suite:
>>> None yet. No test suite coordinator at the moment.
>>>
>> I can create the test suite.
>>
>
> Thanks Marcos! (I just added you as the Test Facilitator for this spec.)
>
>

Re: Screen Orientation Status

[Lars Knudsen]

Hi Art,

thanks and yes - I think we can get some good stuff done here!

br
Lars


On Wed, Apr 16, 2014 at 6:34 PM, Arthur Barstow wrote:

> On 4/4/14 3:29 PM, ext Lars Knudsen wrote:
>
>> what happened to the initiative to take a holistic view on
>> DeviceOrientation, Media Queries and orientation lock all together?
>>
>
> Hi Lars,
>
> Based on the minutes from today's Web Mobile meeting [1], it appears you
> and others have found a venue to discuss these related specs and have some
> agreement on a rough plan forward. Thanks to Marcos and WebMob for taking
> the lead here!
>
> -Regards, ArtB
>
> [1] <http://www.w3.org/2014/04/16-webmob-minutes.html#item03>
>
>
>

Re: impact of new gTLDs

[Lars Knudsen]

Hi,

at least, people should be educated in handling the "xn--" to/from unicode
conversions and I am sure a lot of regex validation has to be rewritten
(not just US ASCII chars in the TLD)

Currently, the whole thing seems to be a bit "wild west" of the different
rules, services, prices and more each gTLD owner puts up - and it will
probably have to exist for some years for all developers to fully
understand the consequences

Out of curiosity - could you tell me which gTLD(s) you have been given? are
they "xn--" ones?

br
Lars


On Thu, Jun 12, 2014 at 11:14 AM, Akihiro Koike  wrote:

> Dear All,
>
> We are a registry operator of new generic top-level domain(gTLD).
> Therefore we are interested in the impact of new gTLDs.
> I'd like your thoughts on what kind of impact the appearance of new
> gTLDs has on software implementation.
>
> Best regards.
>
> --
> Akihiro
>
>
>
>
>

Re: impact of new gTLDs

[Lars Knudsen]

On Thu, Jun 12, 2014 at 12:02 PM, Anne van Kesteren 
wrote:

> On Thu, Jun 12, 2014 at 11:14 AM, Akihiro Koike  wrote:
> > We are a registry operator of new generic top-level domain(gTLD).
> > Therefore we are interested in the impact of new gTLDs.
> > I'd like your thoughts on what kind of impact the appearance of new
> > gTLDs has on software implementation.
>
> The continued growth of https://publicsuffix.org/ would be annoying.
>
>
That might be... but personally, I quite enjoy reading about the reasons
for being able to get a gTLD... e.g. ".dog"
(from
https://gtldresult.icann.org/application-result/applicationstatus/applicationdetails/1536
)

"The .DOG top-level domain is for people who love dogs, and for businesses
who provide goods and services related to dogs. The .DOG domain will also
offer those interested in dogs or dog-related products and services a more
effective means to search for products, services, and educational content
about dogs.


The relationship between dogs and humans dates back more than 12,000 years
(source: http:⁄⁄www.britannica.com⁄EBchecked⁄topic⁄167647⁄dog). Before dogs
were kept for social and companionship purposes, they were used for
hunting. Today dogs are used for hunting, pulling, herding, security,
police assistance, military, aiding the handicapped and even therapy. And,
of course, dog is “man’s best friend.”

There are an estimated 400 million dogs in the world (source: Coppinger,
Ray, Dogs: a Startling New Understanding of Canine Origin, Behavior and
Evolution. New York: Scribner, 2001, p. 352). According to the American
Veterinarian Medical Association, there are more than 72 million pet dogs
in the United States alone, with over 43 million households owning one or
more dogs (source: http:⁄⁄www.avma.org⁄reference⁄marketstats⁄ownership.asp).

Increasingly, dogs play a more important role in our everyday lives. With
popular shows dedicated to dog-training and dog-maintenance, people’s
interest and fascination with canines has grown to new heights. We are
confident that the .DOG top-level domain will feed this growing interest
and better the lives of our friendly, affectionate canine companions--and
their owners.

There is a special connection between humans and dogs; we are fully aware
of the benefits dogs offer humans--including affection, friendship, safety,
therapy, and even health benefits. We intend to give dog owners and those
seeking or offering dog-related services and products a more valuable,
easily-identifiable way of connecting with each other and their loving
companions."


> --
> http://annevankesteren.nl/
>
>

Re: impact of new gTLDs

[Lars Knudsen]

Looking at the publicsuffix.org page, it's going to be pretty tricky
maintaing it for the expected ~800 gTLDs to come.  Also because each of
them may have very different rules for how they give them out, what they
will use them for (e.g. I think there is at least one bank that wants to
give all customers .).  Potentially there will be
millions and just deciding on a proper database to keep them in for fast
searches and more (on e.g. publicsuffix.org) will be fun.

Interesting times ahead ;)

I think (hope?) ICANN should seriously have (has?) considered these
scenarios before just going for the monies .. possibly requiring a service
+ specific API from each gTLD holder to be registered on e.g.
"regapi."




On Thu, Jun 12, 2014 at 3:37 PM, Robin Berjon  wrote:

> On 12/06/2014 12:02 , Anne van Kesteren wrote:
>
>> On Thu, Jun 12, 2014 at 11:14 AM, Akihiro Koike  wrote:
>>
>>> We are a registry operator of new generic top-level domain(gTLD).
>>> Therefore we are interested in the impact of new gTLDs.
>>> I'd like your thoughts on what kind of impact the appearance of new
>>> gTLDs has on software implementation.
>>>
>>
>> The continued growth of https://publicsuffix.org/ would be annoying.
>>
>
> Can you think of an alternative? Because it's looking like we're going to
> keep getting a lot of new TLDs.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>

Re: impact of new gTLDs

[Lars Knudsen]

Dear Akihiro,

>From the public documentation, it seems that you are trying to solve an
actual problem, have a pure ASCII gTLD name, be on top of unicode related
issues and not just sell domains out in huge numbers from .jprs.  On top of
this, you are one of the few who actually reach out to check if there might
be issues (on this list).  I think your new gTLD will not be an issue in
the bigger picture of all the "wild west" style registrations out there
that put $$$ from the gold rush of new gTLDs above any concern with
developers.

Thank you for that.

br
Lars


On Fri, Jun 13, 2014 at 3:01 AM, Akihiro Koike  wrote:

>
> On Thu, 12 Jun 2014 11:55:25 +0200
> Lars Knudsen  wrote:
>
> > Out of curiosity - could you tell me which gTLD(s) you have been given?
> are
> > they "xn--" ones?
>
> We are going to provide ".jprs" registry service.
>
> https://gtldresult.icann.org/application-result/applicationstatus/applicationdetails/1752
>
>
>

Re: Screen Orientation Feedback

[Lars Knudsen]

If only someone had pointed out these problems earlier ;)
On Aug 5, 2014 11:17 PM, "Jonas Sicking"  wrote:

> Hi All,
>
> I think the current interaction between the screen orientation and
> device orientation specs is really unfortunate.
>
> Any time that you use the device orientation in order to render
> something on screen, you have to do non-obvious math in order to get
> coordinates which are usable. Same thing if you want to use the device
> orientation events as input for objects which are rendered on screen.
>
> I would argue that these are the by far most common use cases for
>
> I agree that the main problem here is that the deviceorientation spec
> defined that their events should be relative to the device rather than
> to the screen. However we can still fix the problem by simply adding
>
> partial interface DeviceOrientationEvent
> {
>   readonly attribute double? screenAlpha;
>   readonly attribute double? screenBeta;
>   readonly attribute double? screenGamma;
> }
>
> No new events needs to be defined.
>
> I guess we can argue that this should be added to the
> DeviceOrientation spec, but that seems unlikely to happen in practice
> anytime soon. I think we would do developers a disservice by blaming
> procedural issues rather than trying to solve the problem.
>
> I think mozilla would be happy to implement such an addition to the
> DeviceOrientation event (I'm currently checking to make sure). Are
> there other UAs that have opinions (positive or negative) to such an
> addition?
>
> / Jonas
>
>

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[Lars Knudsen]

"Second, I'm still very worried that people will interpret
screen.orientation.angle=0 as portrait. I don't expect to be able to
convince people here to remove the property. However I think it would
be good to at least make it clear in the spec that the .angle property
can not be used to detect portrait vs. landscape."

Maybe it should be clear in the spec if it

1. disregards coherence with other orientation related specs and their
implementations or
2. tries to look over the fence and address issues like: "on any particular
device, setting landscape-primary, if the user holds the device like *this*
the XYZ-readings from DeviceMotion will be *that*"  IMO - a very, very
common use case and a reason to use orientation lock in the first place.

if (1) - go ahead with whatever is done
if (2) - then *please* try to fix it (and involve DeviceMotion/Orientation)

I realize that there are also issues in the DeviceOrientation camp, where
at least iPhones, some Android devices and FirefoxOS KEON seems to report
back values with different orientation and scale using the same webapp
test.  It could be interesting to check with some modern "Landscape
oriented" devices (how the manufacturers decided to hook up the
accelerometer, the mapping to the web engine and if it should flip on
screen rotation) - but they seem hard to find these days.

Anyway - besides the complains about the spec itself, it's nice that there
is at least *some* sort of orientation locking available now ;). Check
these to see the differences between devices:

https://eu1.empirikit.com/mobile/darts/
and
https://eu1.empirikit.com/mobile/accdemo.html

(demos in flux.. I can send a copy if seen valuable)

br
Lars

On Fri, Sep 12, 2014 at 12:52 AM, Jonas Sicking  wrote:

> On Thu, Sep 11, 2014 at 2:19 PM, Arthur Barstow 
> wrote:
> > Mounir and Marcos would like to publish a LCWD of The Screen Orientation
> API
> > and this is a Call for Consensus to do using the latest ED (not yet in
> the
> > LCWD template) as the basis:
> >
> >   
>
> Sorry, my first comment is a naming bikeshed issue. Feel free to
> ignore as it's coming in late, but I hadn't thought of it until just
> now.
>
> It's somewhat inconsistent that we use the term "natural" to indicate
> "the most natural direction based on hardware", but we use the term
> "primary" when indicating "the most natural portrait/landscape
> direction based on hardware".
>
> Why do we use "primary" for one and "natural" for the other?
>
> Second, I'm still very worried that people will interpret
> screen.orientation.angle=0 as portrait. I don't expect to be able to
> convince people here to remove the property. However I think it would
> be good to at least make it clear in the spec that the .angle property
> can not be used to detect portrait vs. landscape.
>
> A informative note in the description of the angle property saying
> something like:
>
> "The value of this property is relative to the "natural" angle of the
> hardware. So for some devices angle will be 0 when the device is in
> landscape mode, and on other devices when the device is in portrait
> mode. Thus this property can not be used to detect landscape vs.
> portrait. The primary use case for this property is to enable doing
> conversions between coordinates relative to the screen and coordinates
> relative to the device (such as the ones returned from the
> DeviceOrientationEvent interface).
>
> In order to check if the device is in portrait or landscape mode,
> instead use the orientation.type property."
>
> Also, I can't find any normative definition of if orientation.angle
> should increase or decrease if the user rotates a device 90 degrees
> clockwise?
>
> / Jonas
>
>