On Mon, Sep 3, 2012 at 8:58 AM, Ian Hickson wrote:
>
> Does it work if you just transform all the points and the line?
(Yeah, that's still way too vague. I'm not sure how to really specify
> this in a manner that's both unambiguous and clear. Any suggestions?)
>
>
I am not 100% sure that this is
On Tue, Sep 4, 2012 at 10:22 AM, Mark Callow wrote:
>
> It is not a rare occurrence on mobile devices. On my tablet WebGL app's
> lose their context every time the tablet goes to sleep. Since the
> timeout is so short, it only take a brief distraction and "poof!" the
> tablet is asleep. The loss c
On Tue, Sep 4, 2012 at 11:04 AM, Ashley Gullen wrote:
> It sounds like the real issue is mobile:
> - it seems pretty difficult to make a desktop lose a context
> - most mobile browsers still use software rendering, or at least haven't
> had GPU acceleration very long, so there are unlikely to be
On Mon, Sep 10, 2012 at 4:49 PM, Jeff Muizelaar wrote:
>
> On 2012-09-10, at 3:43 PM, Vladimir Vukicevic wrote:
>
>
> FWIW, there are also negative performance implications to clamping samples
> to the source rect. Many graphics APIs do not support this kind sampling,
> and supporting this behavio
Greetings,
Looking at the discussion archives, I saw that there have been proposals in
the past for exposing anti-aliasing related features to the 2D canvas
rendering context. I realize these proposals met significant opposition
each time. Nonetheless, I would like to quickly re-open the discussi
On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
> On Mon, Nov 12, 2012 at 2:36 PM, Justin Novosad wrote:
>
>> Any thoughts?
>>
>
> We'd have to define what happens when you use subpixel antialiasing
> "incorrectly", because we can be pr
On Wed, Nov 14, 2012 at 3:51 PM, Robert O'Callahan wrote:
> On Wed, Nov 14, 2012 at 12:48 PM, Justin Novosad wrote:
>
>> On Wed, Nov 14, 2012 at 2:51 PM, Robert O'Callahan
>> wrote:
>>
>>> We could keep two copies of the canvas buffer: one rendered wi
On Wed, Nov 14, 2012 at 8:07 PM, Fred Andrews wrote:
>
> The canvas that scripts draw into could be over-sized with the UA down
> sampling this to
> fit the target size and taking into account the sub-pixel screen layout
> when doing so.
>
>
Obviously, that would be costly (x3 pixels), but I thin
On Mon, Dec 10, 2012 at 1:24 PM, Ian Hickson wrote:
>
> The reason to prefer the current behaviour is if you want to just update a
> small part of an image. For example, if you draw a bit photo, then draw
> text over it, then want to remove the text by just drawing the photo over
> where the text
On Mon, Dec 10, 2012 at 4:04 PM, Rik Cabanier wrote:
>
>
> As Ian said, copying the sprite image to a non-scaled canvas first (which
> most games probably do anyway) works around the issue.
> There is no need for padding in that case.
>
>
Yes, I am sure a lot of games do it already to work around
On Mon, Dec 10, 2012 at 6:53 PM, Rik Cabanier wrote:
>
>
> I assume this would only be for the 9 argument version of drawImage?
>
Yeah, the all dressed version.
>
> FWIW
> I was curious why this bug doesn't show up in WebKit so I looked at the
> implementation.
> They actually catch cases where
On Wed, Dec 12, 2012 at 12:39 PM, Rik Cabanier wrote:
>
> What would be the next step? Should we define a new version of drawImage
> with the extra parameter?
That is one option, but I think a context attribute (like
imageSmoothingEnabled) is also worth considering.
Perhaps image smoothing coul
> I agree. What I meant to say that the spec should specify that resampling
> behavior is undefined with the existing API.
> It would of course be best if WK would fix their code so it follows the
> current spec description and instructs developers to use the new parameter.
>
Yep. That's how I se
On Sun, Dec 16, 2012 at 11:52 PM, Rik Cabanier wrote:
>
>
> On Wed, Dec 12, 2012 at 10:24 AM, Justin Novosad wrote:
>
>>
>>
>> On Wed, Dec 12, 2012 at 12:39 PM, Rik Cabanier wrote:
>>
>>>
>>> What would be the next step? Should we define a
e your sprite maps in globals to avoid this
problem, right?
I guess it would be the same for sprite (sub image) arrays. I don't think
that is much worse that the status quo.
>
> -kg
>
> On Mon, Dec 17, 2012 at 7:23 AM, Justin Novosad
> wrote:
> >
> >
> > On Sun, Dec
> Isn't this the same as what Ian suggested: copy it to a temporary canvas
> and use the temporary canvas scales.
> It seems that you can optimize that case too.
>
Hmm... It would one of those optimizations that only works if you perform
the secret handshake just right.
If I understand correctly,
Thanks Ian.
http://html5.org/tools/web-apps-tracker?from=7588&to=7589
On Tue, Dec 18, 2012 at 1:04 AM, Robert O'Callahan wrote:
> On Tue, Dec 18, 2012 at 6:57 PM, Rik Cabanier wrote:
>
>> Does it matter that this solution is in the image world and not 2d
>> canvas? It seems that this will have a
t
> > accept any drawable image source.
> >
> > Thanks for the prompt action here, this looks like a straightforward
> solution.
> >
> > -kg
> >
> > On Tue, Dec 18, 2012 at 7:03 AM, Justin Novosad
> wrote:
> >> Thanks Ian.
>
ng
> operations to your canvas get flushed, resulting in the scene slowly
> rendering onscreen?
>
Another great reason to batch the calls, as described above.
>
> -kg
>
> On Tue, Dec 18, 2012 at 7:39 AM, Justin Novosad
> wrote:
> > On Tue, Dec 18, 2012 at 10:17 AM,
Another solution is to use an offscreen canvas.
>
>
>>
>> -kg
>>
>> On Tue, Dec 18, 2012 at 7:39 AM, Justin Novosad
>> wrote:
>> > On Tue, Dec 18, 2012 at 10:17 AM, Kevin Gadd
>> wrote:
>> >>
>> >> Sorry, upon reading over the I
On Wed, Jan 9, 2013 at 2:50 PM, Stephen White wrote:
>
>
> Currently, to lower the VRAM footprint and improve performance, we don't do
> a copy in 2d canvas. We temporarily transfer ownership of the texture to
> the compositor at commit time, and block the renderer until the composite
> is comple
On Mon, Mar 11, 2013 at 8:00 PM, Rik Cabanier wrote:
> Do you expect that createImageData creates an internal copy of the
> Uint8ClampedArray object
> or is it live?
>
That only matters if the referenced data is writable, in which case there
probably should be an internal copy. That is not nece
This is a really simple proposal to add support for text decorations in 2D
canvas contexts.
IDL to add to interface CanvasDrawingStyles:
attribute DOMString textDecoration;
It would support all the same modes as the 'text-decoration' CSS property
(except inherit), and default would be 'none'.
W
On Thu, Apr 18, 2013 at 4:44 PM, Rik Cabanier wrote:
>
> This seems very reasonable.
> I wonder if we should use a DOMString or go to something more JavaScript-y
> like a JSON object or an interface with enums.
>
>
I agree that strings are not the best type for this, but you're talking
about a ra
Rik, just to be clear, what you are suggesting is: use IDL enum in the
spec, and implementors could use DOMString just the same.
That sounds OK. However, I would find it unfortunate to re-specify the
behavior of the property in the canvas 2d context spec, when we could just
spec it like 'font' by
On Fri, Jun 14, 2013 at 2:34 PM, Rik Cabanier wrote:
>
>
> 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.
>
>
>
I would like t
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.
On Wed, Jun 19, 2013 at 10:18 PM, Anne van Kesteren wrote:
>
> I think something like
>
> interface ImageBitmap {
> static Promise create(ImageBitmapSource image, optional long sx,
> long sy, long sw, long sh);
> };
>
> would be much nicer.
>
>
I agree it would be nicer, but it seems less consis
On Mon, Jul 1, 2013 at 3:15 PM, Tom Wiltzius wrote:
> On Sun, Jun 30, 2013 at 11:49 PM, Mark Callow >wrote:
>
> > I thought some pretty strong objections were raised to text decoration.
> > Why are you actively developing it?
> >
>
> There were some concerns cited, as well as some unresolved de
On Mon, Jul 8, 2013 at 9:01 AM, Jonas Sicking wrote:
>
> On Jul 3, 2013 4:38 PM, "Justin Novosad" wrote:
> >
> > On Mon, Jul 1, 2013 at 3:15 PM, Tom Wiltzius
> wrote:
> >
> > > On Sun, Jun 30, 2013 at 11:49 PM, Mark Callow <
> callow.m...@a
On Wed, Jul 10, 2013 at 9:37 PM, Rik Cabanier wrote:
> On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson wrote:
>
> > On Wed, 10 Jul 2013, Kenneth Russell wrote:
> > >
> > > ImageBitmap can cleanly address all of the desired use cases simply by
> > > adding an optional dictionary of options.
> >
> >
esort.
On Thu, Jul 11, 2013 at 4:24 PM, Kenneth Russell wrote:
> On Thu, Jul 11, 2013 at 8:29 AM, Justin Novosad wrote:
> >
> >
> > On Wed, Jul 10, 2013 at 9:37 PM, Rik Cabanier
> wrote:
> >>
> >> On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson wrot
On Sun, Jul 14, 2013 at 4:34 PM, Rik Cabanier wrote:
>
>
> On Fri, Jul 12, 2013 at 7:18 AM, Justin Novosad wrote:
>
>> Thanks Ken, that makes it much clearer to me.
>>
>> The main concern I have with all this is the potential for OOM crashes.
>> I'
Hi all,
We've recently started implementing ImageBitmap in Blink. While writing
tests, we quickly realized that it is quite anoying that ImageBitmaps are
completely opaque objects. When converting animation tests that used to
use image elements over to using ImageBitmaps, we're ending up having
On Tue, Jul 16, 2013 at 12:25 AM, Mark Callow wrote:
> On 2013/07/15 10:46, Justin Novosad wrote:
>
> But to circle back to your point, I agree that an exception is a good idea
> to avoid having to hold a triplicate copy in RAM, or having to redecode all
> the time. Better to f
On Wed, Jul 17, 2013 at 6:54 PM, Ian Hickson wrote:
> On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
> > At the same time, I think we should follow a clear pattern for
> > introducing a Promise based API, which the .create() approach would
> > provide.
>
> I don't understand what that means.
>
I th
teImageBitmap).
>
> On Mon, 15 Jul 2013, Justin Novosad wrote:
> >
> > It would be much more convenient if ImageBitmaps exposed their width and
> > height in pixels as read-only attributes. I don't see any technical
> > reason why we couldn't do that.
On Thu, Jul 18, 2013 at 3:18 AM, K. Gadd wrote:
>
>
> >
> > > I thought any decoding isn't supposed to happen until drawImage, so I
> > > don't really understand why this operation involves a callback and a
> > > delay. Making ImageBitmap creation async means that you *cannot* use
> > > this as a
On Thu, Jul 18, 2013 at 5:45 AM, Mark Callow wrote:
> On 2013/07/18 16:34, K. Gadd wrote:
> >
> > I understand the rationale behind gregg's suggestion for flipY, but
> > ultimately don't know if that one makes any sense in a HTML5 context. It
> > basically only exists because of the annoying disag
/wiki/ImageBitmap_Options
-Justin
On Thu, Jul 18, 2013 at 1:22 PM, Justin Novosad wrote:
>
>
>
> On Thu, Jul 18, 2013 at 5:45 AM, Mark Callow
> wrote:
>
>> On 2013/07/18 16:34, K. Gadd wrote:
>> >
>> > I understand the rationale behind gregg's suggesti
On Thu, Jul 18, 2013 at 12:50 PM, Ian Hickson wrote:
> On Wed, 9 Jan 2013, Ashley Gullen wrote:
> >
> > Some developers are starting to design large scale games using our HTML5
> > game engine, and we're finding we're running in to memory management
> > issues. Consider a device with 50mb of tex
On Thu, Jul 18, 2013 at 5:18 PM, Rik Cabanier wrote:
>
>
> On Thu, Jul 18, 2013 at 2:03 PM, Justin Novosad wrote:
>
>> On Thu, Jul 18, 2013 at 12:50 PM, Ian Hickson wrote:
>>
>> > On Wed, 9 Jan 2013, Ashley Gullen wrote:
>> > >
>> > >
On Fri, Jul 19, 2013 at 7:09 AM, Ashley Gullen wrote:
> FWIW, imageBitmap.discard() wouldn't be unprecedented - WebGL allows you to
> explicitly release memory with deleteTexture() rather than letting the GC
> collect unused textures.
>
>
A related issue we have now is with canvas backing stores.
On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson wrote:
>
> This is a quite widely requested feature. What should we do to address
> this request instead?
>
>
What if resetClip restored the clip to what it was at the save call that
created the current state stack level?
In other words, restore the cli
On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier wrote:
>
>
> On Fri, Aug 9, 2013 at 1:40 PM, Justin Novosad wrote:
>
>> On Fri, Aug 9, 2013 at 4:20 PM, Ian Hickson wrote:
>>
>> >
>> > This is a quite widely requested feature. What should
On Mon, Aug 12, 2013 at 4:34 PM, Rik Cabanier wrote:
>
>
> On Mon, Aug 12, 2013 at 1:24 PM, Justin Novosad wrote:
>
>>
>>
>>
>> On Mon, Aug 12, 2013 at 2:15 PM, Rik Cabanier wrote:
>>
>>>
>>>
>>> On Fri, Aug 9, 2013 at 1:
Ok, so here is a simple proposal:
IDL:
enum CanvasSaveMode { "all", "transform", "clip", "transform-and-clip" };
save(optional CanvasSaveMode mode);
Modes:
all: save the entire rendering context state
transform: save only the current transform
clip: save only the current clip
if mode is not spec
On Tue, Aug 20, 2013 at 6:32 PM, Ian Hickson wrote:
> On Thu, 18 Apr 2013, Justin Novosad wrote:
> >
> > This is a really simple proposal to add support for text decorations in
> > 2D canvas contexts.
> >
> > IDL to add to interface CanvasDrawingStyles:
> >
On Thu, Sep 5, 2013 at 11:48 PM, Rik Cabanier wrote:
> All,
>
> we've looked over the algorithm in the Canvas spec that describes how
> strokes are computed. [1]
> We think that this section is making some incorrect assumptions. For
> instance, the dashes are calculated over the total lenght of a
There is another closely related issue that's been discussed before: adding
a redraw callback to 2d canvas. In the past we discussed this for solving
the problem of recoverring from a gpu context loss, but it seems there may
be better reasons to consider adding a redraw callback such as freeing
me
On Sun, Sep 15, 2013 at 11:38 AM, Jasper St. Pierre
wrote:
> But no browsers I tested actually implement the "clipping region" part.
>
That is weird because all the browsers I tested do implement it. Perhaps
something is unclear? What do *you* think that part of the spec means?
As far as I am co
On Fri, Sep 20, 2013 at 2:16 PM, Simon Sarris wrote:
>
> Anywho, I recommend either considering all zero-sized sources as invalid,
> and perhaps giving a more descriptive error, or simply allowing a
> zero-sized canvas to be a valid drawImage argument so that it may run its
> natural course (draw
On Fri, Sep 27, 2013 at 5:05 PM, Ian Hickson wrote:
>
> > Text decoration can theoretically be drawn directly by the application
> > by using font metrics to compute decoration positions, but this is often
> > very complex to do correctly in a truly portable way.
>
> We could add underline metric
On Thu, Oct 10, 2013 at 2:19 AM, Ian Hickson wrote:
> On Wed, 9 Oct 2013, Rik Cabanier wrote:
> > > >
> > > > Yep, this is where assumptions went wrong. Dashes are calculated per
> > > > subpath, not per 'line'/whole path.
> > >
> > > On what basis are you asserting this?
> >
> > see this fiddle:
On Thu, Oct 10, 2013 at 1:37 PM, Rik Cabanier wrote:
>
> The main issue I see with that algorithm is that it does not solve the
>> case where you would want a join and a dashing break at the same point. I
>> think that is an important case to support, in particular for drawing
>> rectangles.
>>
>
On Thu, Oct 10, 2013 at 4:28 PM, Ian Hickson wrote:
> On Thu, 10 Oct 2013, Rik Cabanier wrote:
> >
> > Dean, Roc, Justin,
> >
> > would you change Canvas' stroking behavior so it no longer matches SVG
> > and CSS and your underlying graphics libraries?
>
> Where does CSS define dashing?
>
You ca
On Thu, Oct 10, 2013 at 4:20 PM, Rik Cabanier wrote:
> Dean, Roc, Justin,
>
> would you change Canvas' stroking behavior so it no longer matches SVG and
> CSS and your underlying graphics libraries?
>
My first reflex is to say that of course it would be convenient for
implementors and web develo
On Thu, Oct 10, 2013 at 5:48 PM, Ian Hickson wrote:
> On Thu, 10 Oct 2013, Rik Cabanier wrote:
> >
> > setLineDash([30]);
> > rect(10, 10, 100, 100);
> > rect(10, 110, 100, 100);
> > rect(10, 210, 100, 100);
> > stroke();
> >
> > These rectangles should look the same.
>
> I presume you mean "I wa
On Thu, Oct 10, 2013 at 6:15 PM, Rik Cabanier wrote:
>
>
>
> On Thu, Oct 10, 2013 at 2:48 PM, Ian Hickson wrote:
>
>>
>> Sure. We can support these easily if we implement dashing as the spec says
>> now, by just adding the feature Justin suggested: an annotation on the
>> path that says to reset
>
> On Thu, Oct 10, 2013 at 4:19 PM, Jasper St. Pierre
> wrote:
>
>>
>> I can imagine an implementer assuming it's a direct translation of their
>> underlying API.
>>
>
As an implementer, I can speak to that. When I first laid eyes on the
algorithm, I was expecting that assumption to hold, but the
On Mon, Oct 14, 2013 at 1:54 PM, Rik Cabanier wrote:
> On Fri, Oct 11, 2013 at 6:17 AM, Justin Novosad wrote:
>
>>
>> So far, there are a few differences between the spec and the graphics API
>> I work with (skia) that attracted my attention:
>> 1) the line caps
Robert, I think your argument makes sense. The DrawingBuffer mechanism
described in http://wiki.whatwg.org/wiki/CanvasInWorkers can be made
implicit and hidden under the hood in a way that is just as memory
efficient by using the right combination of read locks and copy-on-write.
However, I have c
On Sun, Oct 13, 2013 at 7:55 PM, David Bruant wrote:
>
> Not directly related, but I imagine requestAnimationFrame doesn't work in
> a worker. How can a script know when to stop drawing on a given canvas?
>
> rAF doesn't work in a worker, but that is easy to work around. You can
have a rAF handle
On Tue, Oct 15, 2013 at 8:30 PM, Kenneth Russell wrote:
> On Tue, Oct 15, 2013 at 4:41 PM, Robert O'Callahan
> wrote:
> > If you squint, WorkerCanvas.transferToImageBitmap is similar to
> detaching a
> > DrawingBuffer. But I don't see a need to reattach a buffer to a canvas
> for
> > further dra
On Wed, Oct 16, 2013 at 4:32 AM, David Bruant wrote:
> Le 16/10/2013 01:26, Robert O'Callahan a écrit :
>
> On Wed, Oct 16, 2013 at 11:55 AM, David Bruant wrote:
>
>> If the main thread is blocked, the app drops frames anyway, no?
>>
>
> Not necessarily. We can allow workers to present frames
On Tue, Oct 15, 2013 at 7:18 PM, Ian Hickson wrote:
>
> On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > On Thu, Oct 10, 2013 at 12:25 PM, Justin Novosad
> wrote:
> > >
> > > http://jsfiddle.net/ZxR6P/1/
> >
> > Yes, that looks like "Align dashes
Also, I think we may have passed the point of no return on this.
setLineDash is already widely supported as currently spec'ed.
On Wed, Oct 16, 2013 at 1:43 PM, Ian Hickson wrote:
> On Wed, 16 Oct 2013, Justin Novosad wrote:
> >
> > No, I don't mean an implied ze
On Wed, Oct 16, 2013 at 3:53 PM, Robert O'Callahan wrote:
> On Thu, Oct 17, 2013 at 6:35 AM, Kenneth Russell wrote:
>
>> Yes, right. That factory method is already spec'ed on the
>> WorkerGlobalScope [1]. It actually returns a Promise, so presumably
>> transferToImageBitmap would have to as well.
On Wed, Oct 16, 2013 at 5:29 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> From: whatwg-boun...@lists.whatwg.org [whatwg-boun...@lists.whatwg.org]
> on behalf of Anne van Kesteren [ann...@annevk.nl]
>
> > On Wed, Oct 16, 2013 at 9:23 PM, Kenneth Russell wrote:
> >> While the Promis
Here is similar concept, but with an API more like WokerCanvas:
The CanvasRenderingContext2D associated with a WorkerCanvas would only
record draw commands, without executing them. The context would be
write-only. When you call commit on the WorkerCanvas, the block of recorded
draw commands would b
On Thu, Oct 17, 2013 at 5:50 PM, Rik Cabanier wrote:
>
>
>
> On Thu, Oct 17, 2013 at 2:28 PM, Robert O'Callahan
> wrote:
>
>> On Fri, Oct 18, 2013 at 6:57 AM, Justin Novosad wrote:
>>
>>> Here is similar concept, but with an API more like W
>
> ctx.drawImage(SpaceShipCanvas); // draw the spaceship <- it might still be
> drawing in the other task
>
> }
>
> .. // other drawing commands for score, controls, etc
>
> } else if(id == "drawMinion") {
>
> ...
>
> } else if(id == "dra
Hi All,
A few weeks ago there was a discussion on the
graphics-dev@chromium.orgmailing list about the idea of adding support
for discarding and restoring
2D canvas contexts.
https://groups.google.com/a/chromium.org/forum/#!topic/graphics-dev/CQJXpXxO6dk
This idea has been discussed in the past o
gt;>> executeTask("drawBackDrop", gameState); // in other task
>>>
>>> executeTask("drawBoss", gameState); // lots of js to draw the boss so
>>> better done in task
>>>
>>>
>>> for(...) //for each minion {
>>>
On Tue, Oct 22, 2013 at 3:07 AM, Mark Callow wrote:
> I say a weak no to the second. Testing can be done with shims and there
> are probably better ways for apps to do resource management.
>
After doing some digging, I totally agree. I found that the webgl debug
utilities use a shim for testing c
On Tue, Oct 22, 2013 at 5:59 PM, Robert O'Callahan wrote:
> On Tue, Oct 22, 2013 at 10:44 PM, Robert O'Callahan >wrote:
>
> > No problem at all. Can you do it? I need to get a WHATWG account :-).
> >
>
> OK, I added the proposal here:
> http://wiki.whatwg.org/wiki/WorkerCanvas
> A couple of chang
On Wed, Oct 23, 2013 at 11:46 AM, Justin Novosad wrote:
>
>
> Interface Transferable is not defined.
>
> Never mind. :-)
On Sun, Oct 27, 2013 at 10:36 PM, Rik Cabanier wrote:
> The outline should be done in such a way that it is not affected by
> winding.
>
Why is that important? Enforcing that can add a lot of complexity to cases
of self intersecting strokes, or line caps that overlap (
http://jsfiddle.net/aBmZ4
paths that are meant to be filled with a given winding rule
into a winding agnostic representation that produces the same result.
On Mon, Oct 28, 2013 at 1:39 PM, Rik Cabanier wrote:
>
>
>
> On Mon, Oct 28, 2013 at 7:04 AM, Justin Novosad wrote:
>
>>
>> On Sun, Oc
Maybe I am missing something, but I think this API could be implemented
entirely in JS without any new canvas APIs. Do you have a counter example?
Or perhaps you have a use case that would be extraordinarily inefficient
using current APIs?
The way I see it, you would need to use an off-screen can
On Tue, Jan 21, 2014 at 5:12 PM, Ian Hickson wrote:
> On Mon, 30 Sep 2013, Justin Novosad wrote:
>
> > However, this is still a more or less unsolved problem despite the best
> > efforts of a large number of very smart people. Let's not hold our
> > breaths.
>
&g
On Tue, Jul 23, 2013 at 2:11 PM, Ian Hickson wrote:
>
> > >> 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
On Thu, Feb 6, 2014 at 2:55 PM, Ian Hickson wrote:
> On Thu, 6 Feb 2014, Justin Novosad wrote:
> >
> > I am looking into correcting Chrome's behavior to make it spec-compliant
> in
> > this case. There is one specific primitive that is proving problematic:
> >
Hello whatwg,
Say you create a new document using
document.implementation.createHTMLDocument(), you get a document without a
browsing context. This means that style and layout will never be calculated
on the document. Some of those calculations are context dependent, so they
can't even be resolve
On Wed, Mar 5, 2014 at 11:42 PM, Rik Cabanier wrote:
>
> Testing all browsers (except IE
> since document.implementation.createHTMLDocument() doesn't work) they seem
> to handle canvas contexts with no browsing context except when you use text.
> Chrome crashes, firefox throws an exception and Sa
On Thu, Mar 6, 2014 at 11:47 AM, Rik Cabanier wrote:
>
>
>
> On Thu, Mar 6, 2014 at 8:31 AM, Justin Novosad wrote:
>
>>
>>
>>
>> On Wed, Mar 5, 2014 at 11:42 PM, Rik Cabanier wrote:
>>
>>>
>>> Testing all browsers (except IE
>
On Thu, Mar 6, 2014 at 1:17 PM, Ian Hickson wrote:
> On Wed, 5 Mar 2014, Rik Cabanier wrote:
> >
> > Testing all browsers (except IE since
> > document.implementation.createHTMLDocument() doesn't work) they seem to
> > handle canvas contexts with no browsing context except when you use
> > text.
On Thu, Mar 6, 2014 at 1:45 PM, Ian Hickson wrote:
> On Thu, 6 Mar 2014, Justin Novosad wrote:
> > How do we interpret that for Path
> > objects? Does adding text to a path count as a case where font style is
> > undefined, or do we defer and resolve the font style when t
On Mon, Mar 10, 2014 at 2:14 PM, Rik Cabanier wrote:
> On Mon, Mar 10, 2014 at 11:07 AM, Joe Gregorio >wrote:
>
> >
> > What part is slow, the decoding and re-encoding, or is just always the
> > encoding step
> > that is slow?
> >
>
> It's decoding/re-encoding of an already constructed path.
C
On Mon, Mar 10, 2014 at 4:22 PM, Rik Cabanier wrote:
>
>
>
> On Mon, Mar 10, 2014 at 11:38 AM, Justin Novosad wrote:
>
>>
>>
>>
>> On Mon, Mar 10, 2014 at 2:14 PM, Rik Cabanier wrote:
>>
>>> On Mon, Mar 10, 2014 at 11:07 AM, Joe Gregorio
On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson wrote:
>
> > I scale down images using context.drawImage. There is no way for me to
> > opt in for which filter method to use. I thought it was a bug first,
> > because I thought context.webkitImageSmoothingEnabled did the job. But
> > it didn't. So I f
On Fri, Mar 14, 2014 at 4:50 PM, Ian Hickson wrote:
> On Fri, 7 Feb 2014, Justin Novosad wrote:
> > > >
> > > > Current text: If the point (x0, y0) is equal to the point (x1, y1),
> > > > or if the point (x1, y1) is equal to the point (x2, y2), or if bo
On Mon, Mar 17, 2014 at 11:35 AM, Dirk Schulze wrote:
>
> > Hmmm, I gave this a bit more thought... To apply the construction
> > algorithm in transformed space, the ellipse parameters (radiusX, radiusY,
> > rotation) would have to be transformed. Transforming the parameters would
> > be intract
On Mon, Mar 17, 2014 at 12:59 PM, Rik Cabanier wrote:
>
>
>
> On Mon, Mar 17, 2014 at 8:45 AM, Justin Novosad wrote:
>
>> On Mon, Mar 17, 2014 at 11:35 AM, Dirk Schulze
>> wrote:
>>
>> >
>> > > Hmmm, I gave this a bit more thought... To
On Mon, Mar 17, 2014 at 2:06 PM, Rik Cabanier wrote:
>
>
>
>
>>> Make a clean cut and define that drawing operators are ignored when
>>> there's a non-invertible matrix.
>>>
>>> I could totally go for that, but you are talking about going back on the
>> spec of a feature that has shipped, as oppo
>
>
>
>> I have a fix in flight that fixes that problem in Blink by storing the
>> current path in transformed coordinates instead. I've had the fix on the
>> back burner pending the outcome of this thread.
>>
>
> That seems like an expensive solution because this causes the coordinates
> to be tra
On Mon, Mar 17, 2014 at 2:18 PM, Rik Cabanier wrote:
>
>
>
> On Mon, Mar 17, 2014 at 1:47 PM, Justin Novosad wrote:
>
>>
>>
>>>
>>>
>>>> I have a fix in flight that fixes that problem in Blink by storing the
>>>> current path
On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze wrote:
> Hi,
>
> I just looked at the definition of Path.addPath[1]:
>
> void addPath(Path path, SVGMatrix? transformation);
>
> SVGMatrix is nullable but can not be omitted all together. Why isn’t it
> optional as well? I think it should be optio
On Wed, Mar 19, 2014 at 5:47 PM, Rik Cabanier wrote:
>
> On Wed, Mar 19, 2014 at 2:22 PM, Justin Novosad wrote:
>>
>>
>> I agree it should be optional, but just to play devil's advocate : you can
>> create an identity SVGMatrix with a simpler bit of code. Just
On Thu, Mar 20, 2014 at 11:23 AM, Rik Cabanier wrote:
>
>
>
> On Thu, Mar 20, 2014 at 7:01 AM, Justin Novosad wrote:
>
>>
>>
>>
>> On Wed, Mar 19, 2014 at 5:47 PM, Rik Cabanier wrote:
>>
>>>
>>> On Wed, Mar 19, 2014 at 2:22 PM, Ju
1 - 100 of 173 matches
Mail list logo
