image rotation and scaling
14 views
Skip to first unread message
dviner
Jan 13, 2009, 9:06:37 PM1/13/09
to Gears Users
It seems like there's been a lot of work relating to image rotation
and scaling in gears, but none of it has actually made it into the
public release. I also see 2 different wiki pages:
http://code.google.com/p/gears/wiki/CanvasAPI and
http://code.google.com/p/gears/wiki/ImagingAPI. In the code base,
there's a image/ subdirectory that seems to have a lot of code and
which utilizes GD under the hood. There's also a canvas/ subdirectory
that also has a lot of code and utilizes Skia under the hood.
As a user, I really just want image rotation (90 degree increments)
and scaling (while maintaining aspect ratio).
What's the status of getting these features into the next release
candidate? I'm happy to contribute code, but to be honest I'm not
sure where I would start since there are 2 similar sections (canvas
and image), and I can't really tell if one is abandoned/deprecated/
left to die or if they actually serve different purposes.
Thanks
Dave
and scaling in gears, but none of it has actually made it into the
public release. I also see 2 different wiki pages:
http://code.google.com/p/gears/wiki/CanvasAPI and
http://code.google.com/p/gears/wiki/ImagingAPI. In the code base,
there's a image/ subdirectory that seems to have a lot of code and
which utilizes GD under the hood. There's also a canvas/ subdirectory
that also has a lot of code and utilizes Skia under the hood.
As a user, I really just want image rotation (90 degree increments)
and scaling (while maintaining aspect ratio).
What's the status of getting these features into the next release
candidate? I'm happy to contribute code, but to be honest I'm not
sure where I would start since there are 2 similar sections (canvas
and image), and I can't really tell if one is abandoned/deprecated/
left to die or if they actually serve different purposes.
Thanks
Dave
Nigel Tao
Jan 14, 2009, 8:12:14 PM1/14/09
to Gears Users
In my understanding, the key point is that both the Imaging or Canvas
APIs are still considered experimental.
In particular, their APIs aren't frozen, and until we finalize an API
that we want to commit to maintaining, neither API has been publically
released. Also, there is enough overlap between the two APIs (the
Canvas API arguably offers a superset of the Image API's
functionality) that it seems silly to try to launch both, and whilst
the Image API (which came first) is more or less complete, the
(currently partially implemented) Canvas API is probably the better
long-term candidate, given that the <canvas> that inspired it is part
of the HTML5 specification.
Unfortunately, I don't know anyone who is actively working on this.
But if you were to pick one API to contribute code to, I would
recommend the Canvas API.
APIs are still considered experimental.
In particular, their APIs aren't frozen, and until we finalize an API
that we want to commit to maintaining, neither API has been publically
released. Also, there is enough overlap between the two APIs (the
Canvas API arguably offers a superset of the Image API's
functionality) that it seems silly to try to launch both, and whilst
the Image API (which came first) is more or less complete, the
(currently partially implemented) Canvas API is probably the better
long-term candidate, given that the <canvas> that inspired it is part
of the HTML5 specification.
Unfortunately, I don't know anyone who is actively working on this.
But if you were to pick one API to contribute code to, I would
recommend the Canvas API.
dviner
Jan 16, 2009, 5:03:05 PM1/16/09
to Gears Users
Hi Nigel,
Sounds like the image/canvas world is in limbo. Which brings 2
questions to my mind.
1. What is required to get one of the 2 APIs into the release? You
mentioned that you are not committed to supporting either API. How do
we get that commitment to move the project forward?
2. If canvas is the better of the 2 APIs (or more likely to be
released), is there a list of action items to complete on the canvas
API?
Personally, I would imagine that designing and solidifying the Imaging
API seems easier and simpler. That is, a set of APIs surrounding
image access and manipulation are fairly well-bounded problem. The
world of HTML 5 is still evolving and changing. As a result, it might
be the better long term candidate, but it also might be years before
HTML 5 solidifies into a deployed (or deployable) form.
Thanks
Dave
Sounds like the image/canvas world is in limbo. Which brings 2
questions to my mind.
1. What is required to get one of the 2 APIs into the release? You
mentioned that you are not committed to supporting either API. How do
we get that commitment to move the project forward?
2. If canvas is the better of the 2 APIs (or more likely to be
released), is there a list of action items to complete on the canvas
API?
Personally, I would imagine that designing and solidifying the Imaging
API seems easier and simpler. That is, a set of APIs surrounding
image access and manipulation are fairly well-bounded problem. The
world of HTML 5 is still evolving and changing. As a result, it might
be the better long term candidate, but it also might be years before
HTML 5 solidifies into a deployed (or deployable) form.
Thanks
Dave
Nigel Tao
Jan 19, 2009, 10:09:41 PM1/19/09
to Gears Users
Yeah, the image/canvas world is indeed in limbo. :-(
You're right in that HTML5 isn't final, but overall I think it's
pretty stable, especially with respect to canvas. For a year or more
now, there are three existing canvas implementations in stable,
shipped browsers: namely Safari, Firefox and Opera. There's enough
deployment that makes breaking backward compatability highly unlikely.
It might seem like re-inventing the wheel to implement a Gears canvas,
given these other implementations, but the motivation for the Gears
canvas was to fill in the gaping hole (i.e. Internet Explorer) in the
list of canvas-enabled browsers, and to also provide Gears-isms like
canvas import from / export to blob, so you can do things like canvas
renderings in a worker thread.
Given that, I think that canvas is still the better API, even though
you're probably right in that the imaging API is probably easier and
simpler.
As for a list of action items (i.e. features) to implement, I think
it's simply "whatever bits of the HTML5 canvas spec are missing".
There are plenty of "Unimplemented"s in
canvas_rendering_context_2d.cc. A nice test suite under gears/test/
manual/canvas would also help. The text-related and shadow-related API
are probably more a nice-to-have than a must-have-for-launch, and I'd
drop the API additions in canvas_rendering_context_2d.cc (e.g.
convolutionTransform, medianFilter, adjustHue, etc.) since they're
unproven, and not necessary for an initial launch.
As for what is required to get this released, I think if a good-
enough, self-consistent feature set is implemented (and thoroughly
tested) then I would argue for release. The main problem at the moment
is simply that nobody is working on completing the feature set.
If you are willing to write the code, then I will be willing to do the
code reviews, and to land your patches. http://code.google.com/p/gears/wiki/ContributingToGears
You're right in that HTML5 isn't final, but overall I think it's
pretty stable, especially with respect to canvas. For a year or more
now, there are three existing canvas implementations in stable,
shipped browsers: namely Safari, Firefox and Opera. There's enough
deployment that makes breaking backward compatability highly unlikely.
It might seem like re-inventing the wheel to implement a Gears canvas,
given these other implementations, but the motivation for the Gears
canvas was to fill in the gaping hole (i.e. Internet Explorer) in the
list of canvas-enabled browsers, and to also provide Gears-isms like
canvas import from / export to blob, so you can do things like canvas
renderings in a worker thread.
Given that, I think that canvas is still the better API, even though
you're probably right in that the imaging API is probably easier and
simpler.
As for a list of action items (i.e. features) to implement, I think
it's simply "whatever bits of the HTML5 canvas spec are missing".
There are plenty of "Unimplemented"s in
canvas_rendering_context_2d.cc. A nice test suite under gears/test/
manual/canvas would also help. The text-related and shadow-related API
are probably more a nice-to-have than a must-have-for-launch, and I'd
drop the API additions in canvas_rendering_context_2d.cc (e.g.
convolutionTransform, medianFilter, adjustHue, etc.) since they're
unproven, and not necessary for an initial launch.
As for what is required to get this released, I think if a good-
enough, self-consistent feature set is implemented (and thoroughly
tested) then I would argue for release. The main problem at the moment
is simply that nobody is working on completing the feature set.
If you are willing to write the code, then I will be willing to do the
code reviews, and to land your patches. http://code.google.com/p/gears/wiki/ContributingToGears
Brad Neuberg
Jan 23, 2009, 7:04:29 PM1/23/09
to gears...@googlegroups.com
I would also throw in that you should focus on the performance of the Canvas API if you were trying to get it working with Gears, since there is already an open source JavaScript library named ExCanvas that gets Canvas working on IE but its slow.
Best,
Brad
bradn...@google.com
Best,
Brad
bradn...@google.com
JMan
Feb 22, 2009, 4:20:50 PM2/22/09
to Gears Users
Will this ever be released?
On Jan 19, 9:09 pm, Nigel Tao <nigel.tao.gn...@gmail.com> wrote:
> Yeah, the image/canvasworld is indeed in limbo. :-(
> now, there are three existingcanvasimplementations in stable,
> list ofcanvas-enabled browsers, and to also provide Gears-isms likecanvasimport from / export to blob, so you can do things likecanvas
On Jan 19, 9:09 pm, Nigel Tao <nigel.tao.gn...@gmail.com> wrote:
> Yeah, the image/canvasworld is indeed in limbo. :-(
>
> You're right in that HTML5 isn't final, but overall I think it's
> pretty stable, especially with respect tocanvas. For a year or more
> You're right in that HTML5 isn't final, but overall I think it's
> now, there are three existingcanvasimplementations in stable,
> shipped browsers: namely Safari, Firefox and Opera. There's enough
> deployment that makes breaking backward compatability highly unlikely.
>
> It might seem like re-inventing the wheel to implement a Gearscanvas,
> given these other implementations, but the motivation for the Gearscanvaswas to fill in the gaping hole (i.e. Internet Explorer) in the
> deployment that makes breaking backward compatability highly unlikely.
>
> It might seem like re-inventing the wheel to implement a Gearscanvas,
> list ofcanvas-enabled browsers, and to also provide Gears-isms likecanvasimport from / export to blob, so you can do things likecanvas
> renderings in a worker thread.
>
> Given that, I think thatcanvasis still the better API, even though
>
> you're probably right in that the imaging API is probably easier and
> simpler.
>
> As for a list of action items (i.e. features) to implement, I think
> it's simply "whatever bits of the HTML5canvasspec are missing".
> simpler.
>
> As for a list of action items (i.e. features) to implement, I think
> There are plenty of "Unimplemented"s in
> canvas_rendering_context_2d.cc. A nice test suite under gears/test/
> manual/canvaswould also help. The text-related and shadow-related API
> canvas_rendering_context_2d.cc. A nice test suite under gears/test/
Nigel Tao
Feb 23, 2009, 8:41:42 AM2/23/09
to Gears Users
I'll just repeat what I said last time:
Jason Wisener
Feb 23, 2009, 8:44:47 AM2/23/09
to gears...@googlegroups.com
Ok thanks for repeating.
It's things like this is why silverlight and adobe air will always beat gears.
-jw
Reply all
Reply to author
Forward
0 new messages