- From: Robin Berjon <robin@robineko.com>
- Date: Mon, 7 Dec 2009 17:15:36 +0100
- To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Cc: "Oksanen Ilkka (Nokia-D/Espoo)" <Ilkka.Oksanen@nokia.com>, public-device-apis <public-device-apis@w3.org>
Hi Anssi,
[my spellchecker insists on calling you "ANSI" — you were meant for standards!]
On Dec 4, 2009, at 16:59 , Anssi Kostiainen wrote:
> On 4.12.2009, at 16.52, ext Robin Berjon wrote:
>> There's an API for that!
>
> An ability to set a [lower] resolution would also help to minimize the run-time memory allocation which should make apps more responsive and generally perform better. I'm sure using a canvas element is not the most efficient way to resize images albeit I like your creative approach ;)
Right :) I was merely trying to push back (gently) to see if we didn't have a simpler solution. I agree that there is value in controlling the options (though I'd rather see them limited, given the complexity that we can open up).
> [NoInterfaceObject]
> interface captureImageOptions {
> attribute unsigned long limit;
> attribute double duration;
> attribute unsigned short width; // [0, 65535] should be enough?
> attribute unsigned short height; // ditto ("640k is enough for everyone" etc.)
> };
Writing the WebIDL is always going to be the easy part here :) Do devices support setting width and height independently? If not which one determines which resolution is chosen? How does one fallback? There are plenty of annoying details to sort out here.
Also, looking forward to an embedded ViewFinder (I'd still like to have some idea of how widespread and hard it is, what the platform limitations are, etc.) shouldn't those options be directly controllable on it?
(Note that the 640k comment you make isn't such a big deal, assuming that authors ever see anything other than a Number, we can compatibly increase it anyway).
--
Robin Berjon
robineko — hired gun, higher standards
http://robineko.com/
Received on Monday, 7 December 2009 16:16:06 UTC