Re: [webkit-dev] Breakpoints in #included .cpp files [Was: Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)]
On Tue, Aug 29, 2017 at 8:48 PM, Simon Fraser wrote: > > On Aug 28, 2017, at 9:46 PM, Geoffrey Garen wrote: > > > >> The line numbers and filenames will be total nonsense if we just > concatenate multiple source files together. But that's very easy to fix if > the script that concatenates the sources also adds a #line statement > between "files" to change the filename and reset the line number to 1. See > https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html (I suspect it will > work just fine for Clang as well). > > > > Our plan is to use #include. That has worked in the past. > > This should be tested before proceeding with the unified build plan. This > has certainly not always worked in the past (for Apple folks, see > rdar://problem/16751849 and rdar://problem/16829492, which is still open). > > Non-working breakpoints would be a show-stopper for many. > Mozilla has been concatenating source files for a number of years. I don't remember that they had to treat static specially but you did have to configure XCode so you could set the breakpoints. See https://dxr.mozilla.org/mozilla-central/source/.lldbinit#17 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] canvas and sRGB
On Mon, May 2, 2016 at 2:59 PM, Dean Jackson wrote: > > On 3 May 2016, at 7:04 AM, Rik Cabanier wrote: > > > > On Mon, May 2, 2016 at 1:58 PM, Simon Fraser > wrote: > >> On May 2, 2016, at 1:45 PM, Rik Cabanier wrote: >> >> All, >> >> with the release of DCI-P3 screen, WebKit began supporting the display of >> high gamut images. >> Specifically, if you have an image with a DCI-P3 profile, its pixels >> render untouched on the new displays. >> >> However, if you try do do any sort of canvas manipulation, you will see >> that the colors are being compressed to sRGB and you will lose the depth of >> the color. >> >> Was it an oversight to always create the canvas imagebuffer in sRGB? [1] >> >> >> No, this was a deliberate choice. We can't change author expectations for >> what getImageData() return. >> > > Now we see different visual output which is also not what an author > expects :-( > > > Since there is no way to create a canvas element with pixel data that is > interpreted to be in anything other than sRGB, this behaviour seems > expected to me. I'm not sure what else could happen? We couldn't magically > make all the canvas elements in the page use P3. If we did that, they > wouldn't match the CSS content. > I don't see why that would be. CSS colors and tagged/untagged images would be color corrected while being drawn just like it happens in HTML. get/putImageData would of course be uncorrected as it works on raw pixels. > The fix is coming: a way to tag the colorspace of the canvas element. > That's great! Do you have an idea how far off that proposal is? > Can you elaborate what is unexpected with getImageData? Is it that css > "red" no longer returns 100% red pixels? > >> If this is as-designed, how can we work around this limitation? >> >> >> With possible future enhancements to the canvas spec that allow authors >> to request backing store with a different format and/or color profile. >> >> >> PS >> I asked the same question on WhatWG. [2] >> >> >> 1: >> https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73 >> 2: >> https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html >> >> >> Simon >> >> >> > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] canvas and sRGB
On Mon, May 2, 2016 at 1:58 PM, Simon Fraser wrote: > On May 2, 2016, at 1:45 PM, Rik Cabanier wrote: > > All, > > with the release of DCI-P3 screen, WebKit began supporting the display of > high gamut images. > Specifically, if you have an image with a DCI-P3 profile, its pixels > render untouched on the new displays. > > However, if you try do do any sort of canvas manipulation, you will see > that the colors are being compressed to sRGB and you will lose the depth of > the color. > > Was it an oversight to always create the canvas imagebuffer in sRGB? [1] > > > No, this was a deliberate choice. We can't change author expectations for > what getImageData() return. > Now we see different visual output which is also not what an author expects :-( Can you elaborate what is unexpected with getImageData? Is it that css "red" no longer returns 100% red pixels? > If this is as-designed, how can we work around this limitation? > > > With possible future enhancements to the canvas spec that allow authors to > request backing store with a different format and/or color profile. > > > PS > I asked the same question on WhatWG. [2] > > > 1: > https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73 > 2: > https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html > > > Simon > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] canvas and sRGB
All, with the release of DCI-P3 screen, WebKit began supporting the display of high gamut images. Specifically, if you have an image with a DCI-P3 profile, its pixels render untouched on the new displays. However, if you try do do any sort of canvas manipulation, you will see that the colors are being compressed to sRGB and you will lose the depth of the color. Was it an oversight to always create the canvas imagebuffer in sRGB? [1] If this is as-designed, how can we work around this limitation? PS I asked the same question on WhatWG. [2] 1: https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73 2: https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0036.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: you should use WTF::Lock and WTF::Condition instead of WTF::SpinLock, WTF::Mutex, WTF::ThreadCondition, std::mutex, std::condition_variable, or std::condition_variable_any
Hi Filip, very interesting to see you change out such a fundamental algorithm! It's amazing that it works. Reading the code, it seems very comparable to Windows' critical sections [1]. Is that the case? Looking at github and msdn, 4000 seems to be the most common number of spins. I believe your code would also useful be outside of WebKit. Have you given any thought on breaking it off and making it part of the operating system? 1: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683476(v=vs.85).aspx On Wed, Aug 19, 2015 at 1:08 PM, Filip Pizlo wrote: > Hi everyone, > > Over the past two weeks or so I’ve been doing some work to improve the > locking primitives that we use in WebKit. These new primitives have > landed, and they are simply called Lock and Condition. You should use Lock > instead of SpinLock, Mutex, or std::mutex, because it combines the best > qualities of those other locks into one simple implementation. You should > use Condition instead of WTF::ThreadCondition, std::condition_variable, or > std::condition_variable_any because Condition is always smaller and > faster. Also, Condition has a richer API for timed wait, which allows you > to use either std::chrono time or the double-based time from > . It can even use our notion of monotonic time. > > Prior to this change, we had to choose between WTF::SpinLock, which was > fast, and WTF::Mutex/std::mutex, which didn’t waste CPU cycles during > contention. After this change, we no longer have to make such choices: the > new Lock is fast and doesn’t waste CPU cycles. > > I’ve already landed changes to all of WebKit that replace all uses of > those other locking primitives with Lock/Condition. > > The specific benefits of these new primitives are: > > - Lock and Condition take 1 byte of space. That’s the total space that > they will ever consume. Contention is handled using thread local data > structures managed by WTF::ParkingLot and that space usage is O(number of > threads). By comparison, WTF::Mutex and std::mutex take 64 bytes on > Darwin. They are usually take a lot of space on all OSes. WTF::SpinLock > takes 4 bytes. So, Lock is 4x more compact than SpinLock and 64x more > compact than std::mutex/WTF::Mutex. > > - Lock is “adaptive”: it will not waste CPU time or power when a lock is > held for a long time. SpinLock will peg a CPU at 100% while it’s trying to > acquire a lock, which makes SpinLock unsuitable for any critical section > that may be held for a while. This means never using SpinLock in critical > sections that do I/O or that may block on other locks. Lock doesn’t have > this problem; like std::mutex and WTF::Mutex, it has the ability to block > threads indefinitely while waking them up as soon as the lock is available > again. WTF::Lock behaves like a spinlock so long as no thread waits for > too long (currently, too long = 40 spins), and otherwise turns into a > queue-based lock with barging (a hot thread that calls lock() just as > another thread is dequeued may barge in, which increases throughput and > somewhat avoids the convoy problem) and random fairness (in the long term, > every contending thread has an equal shot at getting the lock) and > thundering herd avoidance (unlock could cause one thread to try to contend > for the lock, but it won’t ever wake up threads only to have them go back > to sleep). > > - Lock is very fast in the uncontended case. Locking and unlocking fast > paths are just inline CAS instructions (or LL/SC sequences on ARM and > friends). This makes Lock about 3x faster than some system mutexes, and > within 2x of a spin lock. For Lock performance details, see > http://trac.webkit.org/changeset/188169/trunk/Source/WTF/ChangeLog, > http://trac.webkit.org/changeset/188323/trunk/Source/WTF/ChangeLog, and > http://trac.webkit.org/changeset/188374/trunk/Source/WTF/ChangeLog. > > - Lock is very fast in the case of microcontention. Microcontention is > when you have multiple threads all piling up on a lock that is held for a > short time. You may remember that this case is important in WebKit, in > particular in our parallel GC: https://trac.webkit.org/changeset/117478, > https://www.webkit.org/blog/2136/on-spinlocks-and-sleep/. Well, Lock > takes all of the good ideas from the WTF::SpinLock, which was our previous > best answer for microcontention. Lock is up to 100x faster than WTF::Mutex > and std::mutex in case of microcontention on some OSes. > > - Condition::notifyOne()/notifyAll() are just a fast inlined > load-and-branch in the case that nobody is waiting on the condition. This > feature, combined with the fact that Condition can be used with Lock, and > the fact that Lock is very fast to acquire and release, means that > producer/consumer scenarios can run up to 58x faster with Lock/Condition > than with Mutex/ThreadCondition or std::mutex/std::condition_variable. For > Condition performance details, see > http://trac.webkit.org/changeset/188594/trunk/Sour
Re: [webkit-dev] Adding support for gradient midpoint
On Tue, Sep 30, 2014 at 9:30 AM, Darin Adler wrote: > > On Sep 29, 2014, at 1:57 PM, Benjamin Poulain > wrote: > > > > What is the bug number for tracking this? > > https://bugs.webkit.org/show_bug.cgi?id=137171 Thanks! I accidentally sent the reply just to Benjamin. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding support for gradient midpoint
All, I'm planning on adding support for gradient midpoints.[1] Since this is such a small addition, the feature will not be behind a feature flag and will be enabled by default. Let me know if you have questions or concerns with this approach 1: http://dev.w3.org/csswg/css-images-4/#color-interpolation-hint ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Wed, May 7, 2014 at 9:32 PM, Ryosuke Niwa wrote: > On Wed, May 7, 2014 at 9:08 PM, Rik Cabanier wrote: > >> On Wed, May 7, 2014 at 7:58 PM, Brady Eidson wrote: >> >>> >>> On May 7, 2014, at 5:38 PM, Rik Cabanier wrote: >>> >>> On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain wrote: >>> >>>> On 5/7/14, 4:13 PM, Benjamin Poulain wrote: >>>> >>>>> On 5/7/14, 3:52 PM, Filip Pizlo wrote: >>>>> >>>>>> Exactly. Ben, Oliver, and others have made arguments against web >>>>>> workers. Rik is not proposing web workers. We already support them. >>>>>> The >>>>>> point is to give API to let developers opt into behaving nicely if >>>>>> they >>>>>> are already using web workers. >>>>>> >>>>> >>>>> I have nothing against Web Workers. They are useful to dispatch >>>>> background tasks. >>>>> >>>>> They are basically the Web equivalent dispatch_async() of GCD, which is >>>>> already a very useful tool. >>>>> >>>>> What you are suggesting is useful for making Web Workers the tool to do >>>>> high performance multi-thread computation. >>>>> I don't think Web Workers are a great tool for that job at the moment. >>>>> I >>>>> would prefer something along TBB, GCD or something like that. >>>>> >>>>> >>>>> For high performance computation, I think a more useful API would be >>>>> something like TBB parallel_for with automatic chunking. >>>>> It is actually had to do faster than that with the number of cores >>>>> unless you know your task very very well. >>>>> >>>>> It would be a little more work for us, but a huge convenience for the >>>>> users of Web Workers. >>>>> >>>> >>>> After chatting with Filip, it seems such a model is unlikely to happen >>>> anytime soon for JavaScript. >>>> >>>> In the absence of any tasks/kernels model, I am in favor of exposing a >>>> "good number of thread" API. It is definitely better than nothing. >>> >>> >>> Do we know what this number would be? My guess would be the number of >>> cores for "regular" systems... >>> >>> >>> Define “regular” systems: >>> >> >> "regular" systems are those were all running CPU's are of the same type. >> There are some exotic systems where some CPU's are much faster than others. >> I'm unsure what we should return there. >> >> >>> As Ryosuke mentioned, for systems that run on battery power (read: a >>> vast majority of systems), keeping cores asleep to preserve battery life is >>> often preferable to the user instead of waking up all available hardware >>> and building up heat. >>> >> >> Actually, spinning up more cores while on battery power might be more >> efficient. >> > > This depends on the kinds of workloads. > > I'm having a hard time finding good data, but take this chart for >> instance: http://www.anandtech.com/show/7903/samsung-galaxy-s-5-review/5 >> Let's say you have a task that would take 1 core 4 seconds. This would >> mean 4 x 2612mw = 10456mw >> Now if you can divide it over 4 cores: display = 854 (AMOLED), cpu core >> (simplified) = 2612 - 854 = 1758mw -> 854 + (4 x 1758mw) = 7886mw >> > > If your app wasn't doing anything, one of the CPU is bound to be awaken by > other daemons and system kernel itself. So keeping one of the cores awake > is relatively cheap. So you can't just add or subtract wattage like that. > I agree; this was just a simplified example. I can't find precise data on how much a power a CPU uses. > On the desktop world, Intel Turbo boost [1] boosts single thread >> performance but at the expense of making the CPU run much hotter. >> > > Precisely because of this technology, doing all the work in a single > thread might be faster in some cases. > I just brought this up to highlight that running a single thread might use more power than breaking it up. > Putting an even load will reduce power usage so the ratio of operator/watt >> will improve There's a paper from NVidia that also describes this [2]. >> >> Just because you can break up the work, doesn't mean that you do MORE >> work. >> >> >>> Also, what type of cores? Physical cores, or logical cores? >>> >> >> It would be logical cores. I think we're all compiling and running WebKit >> with hyper-threading turned on so it seems to work fine for parallel >> processing these days. >> > > That's because compiling C code happens to fall within a set of workloads > that could benefit from running concurrently with SMT/HyperThreading. > > OS X's scheduler, for example, appears to have been very carefully tuned > not to schedule two high priority jobs to two logical cores on a single > physical core when there are more physical cores available. > Interesting! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Wed, May 7, 2014 at 7:15 PM, Steven Coul (scoul) wrote: > Naive question(s) here. > > Why does the physical number of cores ( and that is not necessarily the > number of actionable native threads ) matter? > Let's say I have a task that takes 48s and I can break it in any number of pieces. I create 8 workers to crunch numbers. However, my system only has 6 cpus. Total running time will be 12s (4 cpu's are idle for half the time) If I knew there were 6, I could break it into 6 pieces -> total running time = 8s > I would expect a mature system to do the best it can with hardware, in > what the software has asked for it. Some tasks are sleepy, some are IO > bound, some CPU - this is the job of the host kernel to cope. > Agreed. You can have any number of I/O-bound threads and it's up to the kernel to manage those. > Whilst I can accept that there are some tasks for which you may want to > craft your number of workers for to get the best CPU/GPU through put - this > sounds to be to be in the realm of something for which you probably > shouldn’t be coding in javascript inside a web browser for. > Eli had good use cases in his proposal: http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases > ( I’m also not immune to concern about security re: fingerprinting - but > then, how much information do you really get from that? Given the > propensity to use virtual machines / cloud - the number of “processors” is > pretty mutable ). > > Personally, I like to control CPU usage - I’m happy restricting my > browser to 2 cores - so the others are free for other tasks as a developer > - you can’t ask an uninformed user to handle cpu binding - so relying on > the host OS to “do the best it can” and assuming you have say 1..4 “cores” > in an app should work. > > Anything else is high-performance computing. I’m not convinced that a > web-browser is the place to worry about that. > > I’m also leary of anything not standards based - so perhaps *somebody* > should push for a standard whereby you can ask the host os ‘ how many > threads can you handle right now?” - which may or may not be number of > cores - depending on system load. > I think we can eventually do that. The issue is that the problem quickly spirals out of control which makes finding a solution and coming to a consensus harder. > On May 7, 2014, at 7:38 PM, Rik Cabanier wrote: > > > > > On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain wrote: > >> On 5/7/14, 4:13 PM, Benjamin Poulain wrote: >> >>> On 5/7/14, 3:52 PM, Filip Pizlo wrote: >>> >>>> Exactly. Ben, Oliver, and others have made arguments against web >>>> workers. Rik is not proposing web workers. We already support them. The >>>> point is to give API to let developers opt into behaving nicely if they >>>> are already using web workers. >>>> >>> >>> I have nothing against Web Workers. They are useful to dispatch >>> background tasks. >>> >>> They are basically the Web equivalent dispatch_async() of GCD, which is >>> already a very useful tool. >>> >>> What you are suggesting is useful for making Web Workers the tool to do >>> high performance multi-thread computation. >>> I don't think Web Workers are a great tool for that job at the moment. I >>> would prefer something along TBB, GCD or something like that. >>> >>> >>> For high performance computation, I think a more useful API would be >>> something like TBB parallel_for with automatic chunking. >>> It is actually had to do faster than that with the number of cores >>> unless you know your task very very well. >>> >>> It would be a little more work for us, but a huge convenience for the >>> users of Web Workers. >>> >> >> After chatting with Filip, it seems such a model is unlikely to happen >> anytime soon for JavaScript. >> >> In the absence of any tasks/kernels model, I am in favor of exposing a >> "good number of thread" API. It is definitely better than nothing. > > > Do we know what this number would be? My guess would be the number of > cores for "regular" systems... > Boris Zbarsky indicated that Firefox figures out how many workers should > run concurrently. Maybe we can reuse that algorithm? > > >> They can already write code that overloads the system but they >>>> currently >>>> have *no* way of writing code that even tries to be well-behaved except >>>> maybe to avoid workers entirely. >>>> >>>> I'm also a little disturbed by arguments agains
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Wed, May 7, 2014 at 7:58 PM, Brady Eidson wrote: > > On May 7, 2014, at 5:38 PM, Rik Cabanier wrote: > > > > > On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain wrote: > >> On 5/7/14, 4:13 PM, Benjamin Poulain wrote: >> >>> On 5/7/14, 3:52 PM, Filip Pizlo wrote: >>> >>>> Exactly. Ben, Oliver, and others have made arguments against web >>>> workers. Rik is not proposing web workers. We already support them. The >>>> point is to give API to let developers opt into behaving nicely if they >>>> are already using web workers. >>>> >>> >>> I have nothing against Web Workers. They are useful to dispatch >>> background tasks. >>> >>> They are basically the Web equivalent dispatch_async() of GCD, which is >>> already a very useful tool. >>> >>> What you are suggesting is useful for making Web Workers the tool to do >>> high performance multi-thread computation. >>> I don't think Web Workers are a great tool for that job at the moment. I >>> would prefer something along TBB, GCD or something like that. >>> >>> >>> For high performance computation, I think a more useful API would be >>> something like TBB parallel_for with automatic chunking. >>> It is actually had to do faster than that with the number of cores >>> unless you know your task very very well. >>> >>> It would be a little more work for us, but a huge convenience for the >>> users of Web Workers. >>> >> >> After chatting with Filip, it seems such a model is unlikely to happen >> anytime soon for JavaScript. >> >> In the absence of any tasks/kernels model, I am in favor of exposing a >> "good number of thread" API. It is definitely better than nothing. > > > Do we know what this number would be? My guess would be the number of > cores for "regular" systems... > > > Define “regular” systems: > "regular" systems are those were all running CPU's are of the same type. There are some exotic systems where some CPU's are much faster than others. I'm unsure what we should return there. > As Ryosuke mentioned, for systems that run on battery power (read: a vast > majority of systems), keeping cores asleep to preserve battery life is > often preferable to the user instead of waking up all available hardware > and building up heat. > Actually, spinning up more cores while on battery power might be more efficient. I'm having a hard time finding good data, but take this chart for instance: http://www.anandtech.com/show/7903/samsung-galaxy-s-5-review/5 Let's say you have a task that would take 1 core 4 seconds. This would mean 4 x 2612mw = 10456mw Now if you can divide it over 4 cores: display = 854 (AMOLED), cpu core (simplified) = 2612 - 854 = 1758mw -> 854 + (4 x 1758mw) = 7886mw On the desktop world, Intel Turbo boost [1] boosts single thread performance but at the expense of making the CPU run much hotter. Putting an even load will reduce power usage so the ratio of operator/watt will improve There's a paper from NVidia that also describes this [2]. Just because you can break up the work, doesn't mean that you do MORE work. > Also, what type of cores? Physical cores, or logical cores? > It would be logical cores. I think we're all compiling and running WebKit with hyper-threading turned on so it seems to work fine for parallel processing these days. > Boris Zbarsky indicated that Firefox figures out how many workers should > run concurrently. Maybe we can reuse that algorithm? > > I think it’s definitely worth looking in to. > I got a reply from Boris and it's not what we're looking for: When a page tries to start a worker, we check whether that origin already has more than N workers running (where N is a pref, defaulting to 20). If it does, we just queue the worker until some of the extant ones finish. Otherwise we look for an idle thread, and if not found start a new one. Idle threads that hang out for more than 30 seconds without doing anything get wound down. Maybe we can keep the current patch that returns the number of available CPU's for now. [3] 1: http://www.intel.com/content/www/us/en/architecture-and-technology/turbo-boost/turbo-boost-technology.html?wapkw=turbo+boost 2: page 12 of http://www.nvidia.com/content/PDF/tegra_white_papers/tegra-whitepaper-0911b.pdf 3: https://bugs.webkit.org/show_bug.cgi?id=132588 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain wrote: > On 5/7/14, 4:13 PM, Benjamin Poulain wrote: > >> On 5/7/14, 3:52 PM, Filip Pizlo wrote: >> >>> Exactly. Ben, Oliver, and others have made arguments against web >>> workers. Rik is not proposing web workers. We already support them. The >>> point is to give API to let developers opt into behaving nicely if they >>> are already using web workers. >>> >> >> I have nothing against Web Workers. They are useful to dispatch >> background tasks. >> >> They are basically the Web equivalent dispatch_async() of GCD, which is >> already a very useful tool. >> >> What you are suggesting is useful for making Web Workers the tool to do >> high performance multi-thread computation. >> I don't think Web Workers are a great tool for that job at the moment. I >> would prefer something along TBB, GCD or something like that. >> >> >> For high performance computation, I think a more useful API would be >> something like TBB parallel_for with automatic chunking. >> It is actually had to do faster than that with the number of cores >> unless you know your task very very well. >> >> It would be a little more work for us, but a huge convenience for the >> users of Web Workers. >> > > After chatting with Filip, it seems such a model is unlikely to happen > anytime soon for JavaScript. > > In the absence of any tasks/kernels model, I am in favor of exposing a > "good number of thread" API. It is definitely better than nothing. Do we know what this number would be? My guess would be the number of cores for "regular" systems... Boris Zbarsky indicated that Firefox figures out how many workers should run concurrently. Maybe we can reuse that algorithm? > They can already write code that overloads the system but they currently >>> have *no* way of writing code that even tries to be well-behaved except >>> maybe to avoid workers entirely. >>> >>> I'm also a little disturbed by arguments against the general usefulness >>> of ncpu. We use it for the parallel JIT and parallel GC because >>> regardless of system load those are *the best* guesses of how many cpus >>> to use. >>> >>> -Fil >>> >>> On May 7, 2014, at 3:24 PM, Rik Cabanier >> <mailto:caban...@gmail.com>> wrote: >>> >>> >>>> >>>> >>>> On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt >>> <mailto:oli...@apple.com>> wrote: >>>> >>>> >>>> On May 7, 2014, at 3:15 PM, Rik Cabanier >>> <mailto:caban...@gmail.com>> wrote: >>>> >>>> >>>>> >>>>> >>>>> On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt >>>> <mailto:oli...@apple.com>> wrote: >>>>> >>>>> >>>>> On May 7, 2014, at 2:41 PM, Rik Cabanier >>>> <mailto:caban...@gmail.com>> wrote: >>>>> > >>>>> > When would I as a user, not want a page or web application >>>>> to be as fast as possible? Has a user ever complained about a >>>>> desktop app that uses too many of his CPU's? I think Oliver's >>>>> point was that other processes might fight for the same CPU >>>>> resources but that is not unexpected for users. >>>>> >>>>> What happen if i go to your website while i'm doing something >>>>> else in the background? What if i'm playing a game while >>>>> waiting for my machine to do something else? What if your >>>>> page is in the background? Or my battery is running low. >>>>> >>>>> >>>>> Sure. However, a page can already do this today. >>>>> This will just give the author a way to make a semi-informed >>>>> decision. Without this, he might just spin up too many threads >>>>> and starve the rest of the system. >>>>> >>>>> You need to stop thinking in terms of a user wanting only one >>>>> thing to happen at a time. >>>>> >>>>> >>>>> I'm not sure if I follow. How would this be any different from a >>>>> regular desktop application? >>>>> >>>> >>>> The argument is that this is not behavi
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt wrote: > > On May 7, 2014, at 3:15 PM, Rik Cabanier wrote: > > > > > On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt wrote: > >> >> On May 7, 2014, at 2:41 PM, Rik Cabanier wrote: >> > >> > When would I as a user, not want a page or web application to be as >> fast as possible? Has a user ever complained about a desktop app that uses >> too many of his CPU's? I think Oliver's point was that other processes >> might fight for the same CPU resources but that is not unexpected for users. >> >> What happen if i go to your website while i'm doing something else in the >> background? What if i'm playing a game while waiting for my machine to do >> something else? What if your page is in the background? Or my battery is >> running low. >> > > Sure. However, a page can already do this today. > This will just give the author a way to make a semi-informed decision. > Without this, he might just spin up too many threads and starve the rest of > the system. > > >> You need to stop thinking in terms of a user wanting only one thing to >> happen at a time. >> > > I'm not sure if I follow. How would this be any different from a regular > desktop application? > > > The argument is that this is not behaviour that users want - the fact that > desktop applications do this is a bug in the programming model. > > APIs like GCD were specifically created to allow a developer to make an > application than can automatically scale (or descale) to match the > behaviour that is best for the user. That’s the model we want to encourage > on the web. > Filip already covered this much better than I could in the webkit bug: https://bugs.webkit.org/show_bug.cgi?id=132588 This proposal is not about inventing a thread/task scheduling mechanism; this is just a way to make an informed guess without having to use a polyfill, ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Wed, May 7, 2014 at 2:57 PM, Benjamin Poulain wrote: > On 5/7/14, 2:47 PM, Oliver Hunt wrote: > >> >> On May 7, 2014, at 2:41 PM, Rik Cabanier wrote: >> >>> >>> When would I as a user, not want a page or web application to be as fast >>> as possible? Has a user ever complained about a desktop app that uses too >>> many of his CPU's? I think Oliver's point was that other processes might >>> fight for the same CPU resources but that is not unexpected for users. >>> >> >> What happen if i go to your website while i'm doing something else in the >> background? What if i'm playing a game while waiting for my machine to do >> something else? What if your page is in the background? Or my battery is >> running low. >> >> You need to stop thinking in terms of a user wanting only one thing to >> happen at a time. >> > > +1 > > And there are actually many bug reports about native apps using too much > CPU when the user is not expecting it (simple tasks and/or the process is > not frontmost). If a simple task is using a lot of CPU, that is a bug and users will move to an application that is more efficient. If my calendar were to drain my battery, I would switch to a calendar app that doesn't do that. As for background tasks making foreground tasks slow, this is something that could be handled by the operating system/browser process (ie http://msdn.microsoft.com/en-us/library/windows/desktop/ms684828(v=vs.85).aspx ) Most users would expect that if one tab mines bitcoins, the tab that runs a game would be slower. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt wrote: > > On May 7, 2014, at 2:41 PM, Rik Cabanier wrote: > > > > When would I as a user, not want a page or web application to be as fast > as possible? Has a user ever complained about a desktop app that uses too > many of his CPU's? I think Oliver's point was that other processes might > fight for the same CPU resources but that is not unexpected for users. > > What happen if i go to your website while i'm doing something else in the > background? What if i'm playing a game while waiting for my machine to do > something else? What if your page is in the background? Or my battery is > running low. > Sure. However, a page can already do this today. This will just give the author a way to make a semi-informed decision. Without this, he might just spin up too many threads and starve the rest of the system. > You need to stop thinking in terms of a user wanting only one thing to > happen at a time. > I'm not sure if I follow. How would this be any different from a regular desktop application? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Wed, May 7, 2014 at 2:21 PM, Dean Jackson wrote: > > On 6 May 2014, at 11:13 am, Rik Cabanier wrote: > > On Mon, May 5, 2014 at 5:52 PM, Simon Fraser wrote: > >> It allows attackers to know even more about my system, exposing more data >> for fingerprinting. >> > > People can already approximate this today. Approximations are fuzzy so > this might hurt performance if you're not a popular platform or change how > the browser implements workers. > > > There is a difference between approximation and clear detection. During > discussion of a related feature on the WebGL list (for exposing the GPU > information to the page), I noted at the time that it would allow any page > in the world to detect you'd spent X thousand dollars on a Mac Pro in the > last 30 days. Being able to detect the number of cores provides more info - > e.g. you spent X + Y thousand dollars for the upgrade. > > "Let's not show that user ads for vacations in Compton... let's show them > the Bahamas instead." > Sure, however for fingerprinting, the algorithm does not have to be precise and could be done today. A quick routine that returns 1 or 2 for cheap machines and > 12 for expensive machines would be enough to separate the audience. The fact that this is so easily accomplished today and we don't have any evidence that this is happening, tells me that it is not that valuable. We're definitely not leaking more information. (FWIW if sites were to do this, I would prefer that they don't needlessly spin up my CPU's and drain my battery) Do you really want a page to know that you have a fancy-pants 24-core Mac >> Pro rather than a little Mac mini? >> > > Yes! > If I have 24 cores ready to do work and the page can put them to use, I > would like it to do so. > At the same time, if I just have a old mac mini, I don't want the page to > launch 24 workers as that will exhaust my memory and cause contention. > > > But as Oliver said, maybe I don't want the page to use all cores. > When would I as a user, not want a page or web application to be as fast as possible? Has a user ever complained about a desktop app that uses too many of his CPU's? I think Oliver's point was that other processes might fight for the same CPU resources but that is not unexpected for users. It seems that people are mostly concerned with this routine returning large values. Maybe we can make it return 8 as a maximum for now and revisit it in a year or so? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Mon, May 5, 2014 at 6:23 PM, Oliver Hunt wrote: > > On May 5, 2014, at 6:13 PM, Rik Cabanier wrote: > > > >> Do you really want a page to know that you have a fancy-pants 24-core >> Mac Pro rather than a little Mac mini? >> > > Yes! > If I have 24 cores ready to do work and the page can put them to use, I > would like it to do so. > At the same time, if I just have a old mac mini, I don't want the page to > launch 24 workers as that will exhaust my memory and cause contention. > > > But I don't have 24 cores available, i have 24 cores installed. You have > no idea what the actual workload of the system is, you don't know whether > any other tabs are also using workers, you only have one piece of > information, and that is nowhere near sufficient to make a reasonable > choice. > Sure, if I have 2 tabs and each one consumes all my CPU resources, things will run at half the speed and maybe even worse because of we would use more memory. How often would that happen though? Even if it did, would it be surprising to the user that things are slower? > A better solution would be to have a WorkerSet API where the browser is > able to make a sensible choice given the current system, system load, power > source, etc, etc > I'm unconvinced that this is something that authors actually want and also sounds more complex than needed. That being said, this is a problem that could be solved in parallel. Nothing in web workers is stopping a browser to implement this underneath web workers. > Generating workloads on the basis of # of installed cores has be attempted > on every environment and it almost always leads to incorrect choices being > made. > I don't think that is true. I know several Adobe applications and libraries that look at the number of CPU's to divide up the workload. Long time ago, I wrote an application that compressed image data over all available CPUs and it was not that hard to optimize this. On May 5, 2014, at 4:58 PM, Filip Pizlo wrote: >> >> I like this. Personally, I don't see any downside. >> >> Is there a bug (on bugs.webkit.org), and if not, can you create one? :-) >> >> -Phil >> >> >> On May 5, 2014 at 4:49:35 PM, Rik Cabanier (caban...@gmail.com) wrote: >> >> All, >> >> there's a thread on blink-dev [1] and whatwg [2] to create a new >> parameter on the navigator object that returns the maximum number of tasks >> that can run in parallel. [3] >> >> Is this something that WebKit would support? >> >> 1: >> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 >> 2: >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-May/254200.html >> 3: http://wiki.whatwg.org/wiki/NavigatorCores >> >> >> > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Mon, May 5, 2014 at 5:52 PM, Simon Fraser wrote: > It allows attackers to know even more about my system, exposing more data > for fingerprinting. > People can already approximate this today. Approximations are fuzzy so this might hurt performance if you're not a popular platform or change how the browser implements workers. > Do you really want a page to know that you have a fancy-pants 24-core Mac > Pro rather than a little Mac mini? > Yes! If I have 24 cores ready to do work and the page can put them to use, I would like it to do so. At the same time, if I just have a old mac mini, I don't want the page to launch 24 workers as that will exhaust my memory and cause contention. > > On May 5, 2014, at 4:58 PM, Filip Pizlo wrote: > > I like this. Personally, I don't see any downside. > > Is there a bug (on bugs.webkit.org), and if not, can you create one? :-) > > -Phil > > > On May 5, 2014 at 4:49:35 PM, Rik Cabanier (caban...@gmail.com) wrote: > > All, > > there's a thread on blink-dev [1] and whatwg [2] to create a new parameter > on the navigator object that returns the maximum number of tasks that can > run in parallel. [3] > > Is this something that WebKit would support? > > 1: > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 > 2: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-May/254200.html > 3: http://wiki.whatwg.org/wiki/NavigatorCores > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On Mon, May 5, 2014 at 4:58 PM, Filip Pizlo wrote: > I like this. Personally, I don't see any downside. > > Is there a bug (on bugs.webkit.org), and if not, can you create one? :-) > Done! https://bugs.webkit.org/show_bug.cgi?id=132588 I volunteer to implement this. (I love threading) > On May 5, 2014 at 4:49:35 PM, Rik Cabanier (caban...@gmail.com) wrote: > > All, > > there's a thread on blink-dev [1] and whatwg [2] to create a new parameter > on the navigator object that returns the maximum number of tasks that can > run in parallel. [3] > > Is this something that WebKit would support? > > 1: > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 > 2: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-May/254200.html > 3: http://wiki.whatwg.org/wiki/NavigatorCores > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
All, there's a thread on blink-dev [1] and whatwg [2] to create a new parameter on the navigator object that returns the maximum number of tasks that can run in parallel. [3] Is this something that WebKit would support? 1: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 2: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-May/254200.html 3: http://wiki.whatwg.org/wiki/NavigatorCores ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove CANVAS_PATH compiler flag where possible
On Wed, Apr 16, 2014 at 1:18 PM, Dirk Schulze wrote: > Hi, > > I would like to ask to remove the CANVAS_PATH compiler flag from WebCore > where possible. At the moment it guards the Path2D object and all related > methods in Canvas like: > > void fill(Path2D path, optional CanvasWindingRule winding); > void stroke(Path2D path); > void clip(Path2D path, optional CanvasWindingRule winding); > > Firefox and Chrome will ship with Path2D enabled in the next release > versions. WebKits implementation is interoperable with Firefox and Chrome. > > The only method on Path2D that just reached consensus but does not ship in > other browsers is addPath(Path2D, optional SVGMatrix?). The risk that it > will change in an not interoperable way is minimal. However, at the moment I would like to guard it behind a compiler flag and > implementations shouldn’t ship with it within the next couple of weeks. > Alternatively, I can remove the IDL method in favor for removing the > CANVAS_PATH compiler flag completely. > Yes, even though the API might not change, some of the language in the spec needs to be cleared up. For instance adding a path with 2 lineto to a path with a moveto and a lineto, will according to the spec result in moveto, lineto, MOVETO, lineto, lineto which is unexpected. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
Could you briefly say what you would like to see addressed? On Tue, Oct 15, 2013 at 10:31 AM, Ryosuke Niwa wrote: > At this point, I don't think we should proceed with the implementation > given the number of concerns other WebKit contributors have raised. > > Let's bring this discussion back to WebApps WG or WHATWG instead of > spamming webkit-dev. > > - R. Niwa > > On Monday, October 14, 2013, Rik Cabanier wrote: >> >> >> On Mon, Oct 14, 2013 at 4:13 PM, Timothy Hatcher wrote: >> >>> On Oct 14, 2013, at 3:44 PM, Rik Cabanier wrote: >>> >>> Isn't focus ring drawn on the canvas? If so, it's important that the >>>>>>> focus ring fits within the canvas. e.g. consider focusing an element of >>>>>>> 100px by 100px inside a canvas of the same size. If the focus ring >>>>>>> were to >>>>>>> be drawn around the element that currently has focus, then the entire >>>>>>> focus >>>>>>> ring would be drawn outside of the visible region. >>>>>>> >>>>>> >>>>> True. That sounds like bad design though. >>>>> >>>> >>>> Why? It doesn't seem particularly strange to have an element occupy the >>>> entire canvas momentarily. >>>> >>> >>> No, but I wouldn't never make the focus ring as large as the canvas. >>> >>> >>> Even if you don't make it full size, if the focus ring is drawn into the >>> canvas buffer, you don't know how much room you need to account for. (If >>> the focused control is near the edge of the canvas.) >>> >> >> The spec says: >> >> draw a focus ring of the appropriate style along the intended path, >> following platform conventions. >> >> >> In one of the email threads I have asked what "along the path" meant but >> there hasn't been an answer... >> I think it's assumed that you leave enough space so the ring fits. There >> isn't even anything in the spec that says that the path should fall in the >> canvas region. >> >> > > -- > Ryosuke Niwa > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Mon, Oct 14, 2013 at 4:13 PM, Timothy Hatcher wrote: > On Oct 14, 2013, at 3:44 PM, Rik Cabanier wrote: > > Isn't focus ring drawn on the canvas? If so, it's important that the >>>>> focus ring fits within the canvas. e.g. consider focusing an element of >>>>> 100px by 100px inside a canvas of the same size. If the focus ring were >>>>> to >>>>> be drawn around the element that currently has focus, then the entire >>>>> focus >>>>> ring would be drawn outside of the visible region. >>>>> >>>> >>> True. That sounds like bad design though. >>> >> >> Why? It doesn't seem particularly strange to have an element occupy the >> entire canvas momentarily. >> > > No, but I wouldn't never make the focus ring as large as the canvas. > > > Even if you don't make it full size, if the focus ring is drawn into the > canvas buffer, you don't know how much room you need to account for. (If > the focused control is near the edge of the canvas.) > The spec says: draw a focus ring of the appropriate style along the intended path, following platform conventions. In one of the email threads I have asked what "along the path" meant but there hasn't been an answer... I think it's assumed that you leave enough space so the ring fits. There isn't even anything in the spec that says that the path should fall in the canvas region. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Mon, Oct 14, 2013 at 2:58 PM, Ryosuke Niwa wrote: > On Mon, Oct 14, 2013 at 2:50 PM, Rik Cabanier wrote: > >> On Mon, Oct 14, 2013 at 2:38 PM, Ryosuke Niwa wrote: >> >>> Sorry, the original email had lots of typos. I've fixed them below: >>> >>> On Mon, Oct 14, 2013 at 2:35 PM, Ryosuke Niwa wrote: >>> >>>> On Mon, Oct 14, 2013 at 2:28 PM, Rik Cabanier wrote: >>>> >>>>> On Mon, Oct 14, 2013 at 1:31 PM, Timothy Hatcher wrote: >>>>> >>>>>> On Oct 14, 2013, at 12:43 PM, Rik Cabanier >>>>>> wrote: >>>>>> >>>>>> Also, how would your suggestion tell the UA about what areas are >>>>>> associated with the elements? What happens if an element is no longer >>>>>> focused? The ring is drawn into the canvas bitmap so those pixels have to >>>>>> be regenerated. >>>>>> >>>>>> >>>>>> Focus rings are usually larger than the control they surround. How is >>>>>> the developer suppose to know the pixel padding needed for each >>>>>> platform's >>>>>> focus ring? Guess and hope for the best? >>>>>> >>>>> >>>>> Why would he need to know this? Is it for the path that describes the >>>>> ring? >>>>> >>>> >>>> Isn't focus ring drawn on the canvas? If so, it's important that the >>>> focus ring fits within the canvas. e.g. consider focusing an element of >>>> 100px by 100px inside a canvas of the same size. If the focus ring were to >>>> be drawn around the element that currently has focus, then the entire focus >>>> ring would be drawn outside of the visible region. >>>> >>> >> True. That sounds like bad design though. >> > > Why? It doesn't seem particularly strange to have an element occupy the > entire canvas momentarily. > No, but I wouldn't never make the focus ring as large as the canvas. > > Wouldn't you have the same problem with focusable content in an >> "overflow:hidden" element that just fits its child? >> > > Even if this was broken, we could fix that because the focus ring is > currently drawn by the UA. On the other hand, we're exposing an API to > manually draw the focus ring on the canvas, then it's much harder to fix it. > > And I'm getting totally confused by this whole discussion because you've > been kept telling us that UA could draw focus ring later to mitigate > issues/concerns we've raised while at the same time telling us that authors > have to call these functions whenever focus changes to redraw the focus > ring. > > It's one or the other. The focus ring should be either drawn by this API, > in which case, all the concerns we've raised thus far stands; or that the > focus ring is drawn by UA at its discretion (potentially synchronously) in > which case the function name should be changed. > Sorry if I was confusing. These API are a bit odd so it could be that some subtleties were lost. For drawSystemFocusRing, the UA will always draw the ring immediately/synchronously when you call drawSystemFocusRing. For drawCustomFocusRing, the UA *could* draw the ring immediately (in case of high contrast), or it returns true so the author should draw it. The author can decide when he draws the ring. > > Would drawing the system focus ring taint the canvas pixels? (Drawing >>>>>> form controls into canvas via SVG images and has been >>>>>> considered taint worthy because it could leak the user's UI theme.) >>>>>> >>>>> >>>>> I'm unsure if it should taint the canvas. How much information would >>>>> be leaked that isn't already available through other means? >>>>> >>>> >>>> It may, for example, leak information as to whether user's machine is >>>> in high contrast mode, which is another dimension for finger-printing user. >>>> >>> >> Yes, maybe this should taint. Dominic, what do you think? >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Mon, Oct 14, 2013 at 2:46 PM, Chris Fleizach wrote: > > On Oct 14, 2013, at 2:28 PM, Rik Cabanier wrote: > > > > > On Mon, Oct 14, 2013 at 1:31 PM, Timothy Hatcher wrote: > >> On Oct 14, 2013, at 12:43 PM, Rik Cabanier wrote: >> >> Also, how would your suggestion tell the UA about what areas are >> associated with the elements? What happens if an element is no longer >> focused? The ring is drawn into the canvas bitmap so those pixels have to >> be regenerated. >> >> >> Focus rings are usually larger than the control they surround. How is the >> developer suppose to know the pixel padding needed for each platform's >> focus ring? Guess and hope for the best? >> > > Why would he need to know this? Is it for the path that describes the ring? > > >> Would drawing the system focus ring taint the canvas pixels? (Drawing >> form controls into canvas via SVG images and has been >> considered taint worthy because it could leak the user's UI theme.) >> > > I'm unsure if it should taint the canvas. How much information would be > leaked that isn't already available through other means? > > > Hi, > > I think it would be likely that the OS would draw their focus ring on top > in a different context and the canvas wouldn't have to be responsible to > repaint. > Doesn't that require another buffer that has the same memory size as the canvas? Or did you mean that it draws the focus ring on top right after the canvas backing store is composited? drawSystemFocusRing would be dropped with this proposal, right? > > Which leaves the case where the canvas sees drawCursor fails and then > tries to draw its own, which seems somewhat strange to me. How would the > web page know what the user wanted. > I'm unsure what you mean. could you rephrase? > There could be a variety of high contrast cursors that the user might want > to use > My patch looks like this: GraphicsContext* c = drawingContext(); if (c) c->drawFocusRing(m_path, 1, 1, RenderTheme::focusRingColor()); Should that use the focus ring color and style that the user picked? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Mon, Oct 14, 2013 at 2:38 PM, Ryosuke Niwa wrote: > Sorry, the original email had lots of typos. I've fixed them below: > > On Mon, Oct 14, 2013 at 2:35 PM, Ryosuke Niwa wrote: > >> On Mon, Oct 14, 2013 at 2:28 PM, Rik Cabanier wrote: >> >>> On Mon, Oct 14, 2013 at 1:31 PM, Timothy Hatcher wrote: >>> >>>> On Oct 14, 2013, at 12:43 PM, Rik Cabanier wrote: >>>> >>>> Also, how would your suggestion tell the UA about what areas are >>>> associated with the elements? What happens if an element is no longer >>>> focused? The ring is drawn into the canvas bitmap so those pixels have to >>>> be regenerated. >>>> >>>> >>>> Focus rings are usually larger than the control they surround. How is >>>> the developer suppose to know the pixel padding needed for each platform's >>>> focus ring? Guess and hope for the best? >>>> >>> >>> Why would he need to know this? Is it for the path that describes the >>> ring? >>> >> >> Isn't focus ring drawn on the canvas? If so, it's important that the >> focus ring fits within the canvas. e.g. consider focusing an element of >> 100px by 100px inside a canvas of the same size. If the focus ring were to >> be drawn around the element that currently has focus, then the entire focus >> ring would be drawn outside of the visible region. >> > True. That sounds like bad design though. Wouldn't you have the same problem with focusable content in an "overflow:hidden" element that just fits its child? > >> Would drawing the system focus ring taint the canvas pixels? (Drawing >>>> form controls into canvas via SVG images and has been >>>> considered taint worthy because it could leak the user's UI theme.) >>>> >>> >>> I'm unsure if it should taint the canvas. How much information would be >>> leaked that isn't already available through other means? >>> >> >> It may, for example, leak information as to whether user's machine is in >> high contrast mode, which is another dimension for finger-printing user. >> > Yes, maybe this should taint. Dominic, what do you think? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Mon, Oct 14, 2013 at 1:31 PM, Timothy Hatcher wrote: > On Oct 14, 2013, at 12:43 PM, Rik Cabanier wrote: > > Also, how would your suggestion tell the UA about what areas are > associated with the elements? What happens if an element is no longer > focused? The ring is drawn into the canvas bitmap so those pixels have to > be regenerated. > > > Focus rings are usually larger than the control they surround. How is the > developer suppose to know the pixel padding needed for each platform's > focus ring? Guess and hope for the best? > Why would he need to know this? Is it for the path that describes the ring? > Would drawing the system focus ring taint the canvas pixels? (Drawing form > controls into canvas via SVG images and has been considered > taint worthy because it could leak the user's UI theme.) > I'm unsure if it should taint the canvas. How much information would be leaked that isn't already available through other means? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Fri, Oct 11, 2013 at 12:14 AM, Chris Fleizach wrote: > Hi > > The naming of these methods also made it a bit confusing for me. > > It appears that drawCustomFocusRing just updates the accessibility > rectangle -- while the system variant does that, and draws the normal focus > ring. > In the former case, it doesn't really draw anything, it just allows an AT > to retrieve the bounding box of the focused item. > > It seems that for this to be useful for ATs, you'd have to iterate every > object in your canvas and call at least drawCustomFocusRing once. Then when > the item actually did become focused, you'd have to call > drawSystemFocusRing. > > I don't know what others think, but I think accessibility work is best > done on demand. > > In this case I could imagine something like a RectangleRequestEvent be > dispatched that the canvas could intercept. > The event would have the Element in question as a data member of the Event. > The canvas could set the rectangle in the event for that element > > Then this work would only have to be done when requested > This doesn't seem very workable and forces the developer to do more work. If you think about how a canvas application woks, during the drawing cycle, there's an understanding that a control is drawn. At that point, it's straightforward to call drawCustom/SystemFocusRing and draw the focus area. I suspect that most UI implementations do the same (probably by checking the focused attribute). Also, how would your suggestion tell the UA about what areas are associated with the elements? What happens if an element is no longer focused? The ring is drawn into the canvas bitmap so those pixels have to be regenerated. On Oct 10, 2013, at 7:32 PM, Rik Cabanier wrote: > > > > > On Thu, Oct 10, 2013 at 7:26 PM, Ryosuke Niwa wrote: > >> On Thu, Oct 10, 2013 at 7:21 PM, Rik Cabanier wrote: >> >>> On Thu, Oct 10, 2013 at 7:19 PM, Ryosuke Niwa wrote: >>> >>>> On Thu, Oct 10, 2013 at 7:14 PM, Rik Cabanier wrote: >>>> >>>>> On Thu, Oct 10, 2013 at 7:07 PM, Ryosuke Niwa wrote: >>>>> >>>>>> The spec. text is also misleading in saying that >>>>>> >>>>>> The drawSystemFocusRing(element) method, when invoked, must run the >>>>>> following steps: >>>>>> >>>>>> If I understood your reply correctly, these are steps that need to be >>>>>> ran continuously? Or is it that steps 2 & 3 must run upon the currently >>>>>> focused element being changed. The specification needs to revised to >>>>>> clarify this. >>>>>> >>>>> >>>>> I think non-normative text or a note could be added to make this more >>>>> clear. In general, the function should be called when the focus changes or >>>>> the element is relocated and the canvas should be redrawn. >>>>> >>>> ... >>>> >>>>> As is, the specification reads as if the author needs to repaint and >>>>>> call drawSystemFocusRing upon focus change. >>>>>> >>>>> >>>>> That is correct and what should happen. >>>>> >>>>> >>>> That seems to contract what you've said earlier: >>>> >>>>> What is an AT? :-) You don't call drawSystemFocusRing when an element >>>>> is focused. You *always* call it and if it is focused, a ring will be >>>>> drawn. In all cases, the accessibility software is notified of the area. >>>>> >>>> (AT stands for http://en.wikipedia.org/wiki/Assistive_technology). >>>> >>>> Am I correct in saying that the author needs to call this function each >>>> and every time an element "inside" the canvas is focused? >>>> >>> >>> No, he needs to ALWAYS call this function wether it's focused or not. >>> >> >> I understand that. My point is that the author has to explicitly repaint >> the canvas and call drawSystemFocusRing when the focus changed for the >> focus ring to be drawn. i.e. UA can't later decide to draw the focus ring >> on its own. >> > > That is correct. The accessibility software can though since it just draws > on top of the browser windows (and so can the web inspector) > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Thu, Oct 10, 2013 at 7:26 PM, Ryosuke Niwa wrote: > On Thu, Oct 10, 2013 at 7:21 PM, Rik Cabanier wrote: > >> On Thu, Oct 10, 2013 at 7:19 PM, Ryosuke Niwa wrote: >> >>> On Thu, Oct 10, 2013 at 7:14 PM, Rik Cabanier wrote: >>> >>>> On Thu, Oct 10, 2013 at 7:07 PM, Ryosuke Niwa wrote: >>>> >>>>> The spec. text is also misleading in saying that >>>>> >>>>> The drawSystemFocusRing(element) method, when invoked, must run the >>>>> following steps: >>>>> >>>>> If I understood your reply correctly, these are steps that need to be >>>>> ran continuously? Or is it that steps 2 & 3 must run upon the currently >>>>> focused element being changed. The specification needs to revised to >>>>> clarify this. >>>>> >>>> >>>> I think non-normative text or a note could be added to make this more >>>> clear. In general, the function should be called when the focus changes or >>>> the element is relocated and the canvas should be redrawn. >>>> >>> ... >>> >>>> As is, the specification reads as if the author needs to repaint and >>>>> call drawSystemFocusRing upon focus change. >>>>> >>>> >>>> That is correct and what should happen. >>>> >>>> >>> That seems to contract what you've said earlier: >>> >>>> What is an AT? :-) You don't call drawSystemFocusRing when an element >>>> is focused. You *always* call it and if it is focused, a ring will be >>>> drawn. In all cases, the accessibility software is notified of the area. >>>> >>> (AT stands for http://en.wikipedia.org/wiki/Assistive_technology). >>> >>> Am I correct in saying that the author needs to call this function each >>> and every time an element "inside" the canvas is focused? >>> >> >> No, he needs to ALWAYS call this function wether it's focused or not. >> > > I understand that. My point is that the author has to explicitly repaint > the canvas and call drawSystemFocusRing when the focus changed for the > focus ring to be drawn. i.e. UA can't later decide to draw the focus ring > on its own. > That is correct. The accessibility software can though since it just draws on top of the browser windows (and so can the web inspector) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Thu, Oct 10, 2013 at 7:19 PM, Ryosuke Niwa wrote: > On Thu, Oct 10, 2013 at 7:14 PM, Rik Cabanier wrote: > >> On Thu, Oct 10, 2013 at 7:07 PM, Ryosuke Niwa wrote: >> >>> The spec. text is also misleading in saying that >>> >>> The drawSystemFocusRing(element) method, when invoked, must run the >>> following steps: >>> >>> If I understood your reply correctly, these are steps that need to be >>> ran continuously? Or is it that steps 2 & 3 must run upon the currently >>> focused element being changed. The specification needs to revised to >>> clarify this. >>> >> >> I think non-normative text or a note could be added to make this more >> clear. In general, the function should be called when the focus changes or >> the element is relocated and the canvas should be redrawn. >> > ... > >> As is, the specification reads as if the author needs to repaint and >>> call drawSystemFocusRing upon focus change. >>> >> >> That is correct and what should happen. >> >> > That seems to contract what you've said earlier: > >> What is an AT? :-) You don't call drawSystemFocusRing when an element is >> focused. You *always* call it and if it is focused, a ring will be drawn. >> In all cases, the accessibility software is notified of the area. >> > (AT stands for http://en.wikipedia.org/wiki/Assistive_technology). > > Am I correct in saying that the author needs to call this function each > and every time an element "inside" the canvas is focused? > No, he needs to ALWAYS call this function wether it's focused or not. > > If so, there is no way for AT to detect/enumerate all focusable areas > upfront to let users know of which areas are focusable (before focusing any > element). > > - R. Niwa > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Thu, Oct 10, 2013 at 7:13 PM, Ryosuke Niwa wrote: > On Thu, Oct 10, 2013 at 7:09 PM, Rik Cabanier wrote: > >> On Thu, Oct 10, 2013 at 7:02 PM, Ryosuke Niwa wrote: >> >>> On Thu, Oct 10, 2013 at 6:56 PM, Rik Cabanier wrote: >>> >>>> On Thu, Oct 10, 2013 at 6:08 PM, Ryosuke Niwa wrote: >>>> >>>>> On Thu, Oct 10, 2013 at 1:35 PM, Rik Cabanier wrote: >>>>>> >>>>>> Support (behind runtime flags) has landed in: >>>>>>>> - Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=540456 >>>>>>>> - chrome: >>>>>>>> https://code.google.com/p/chromium/issues/detail?id=261998 >>>>>>>> >>>>>>>> Focus rings associate elements that are in a canvas tag with areas >>>>>>>> of the canvas. >>>>>>>> If the user tabs into the hidden element or the accessibility >>>>>>>> software selects them, these methods will draw or let the author draw >>>>>>>> the >>>>>>>> focus rings. >>>>>>>> >>>>>>> >>>>>>> How does this API address this use case? It seems like each Web app >>>>>>> needs to explicitly opt-in and manually draw focus ring? >>>>>>> >>>>>> >>>>>> That is correct. This is code that the canvas developer needs to >>>>>> implement. >>>>>> >>>>>> I'm not sure if that's a good accessibility API given that many >>>>>>> authors don't even use most basic accessibility feature such as ARIA >>>>>>> roles. >>>>>>> >>>>>> >>>>>> There's not much we can do about this. However, for authors that DO >>>>>> want to provide this, there's is currently no way to provide >>>>>> accessibility >>>>>> for canvas. >>>>>> >>>>>> >>>>>>> >>>>>>> e.g. why can't UA automatically draw focus ring on top of the canvas? >>>>>>> >>>>>> >>>>>> The problem is that the UA doesn't know what part of the canvas area >>>>>> corresponds with the hidden element. This API is designed to make that >>>>>> association >>>>>> >>>>> >>>>> Why can't authors provide that information by placing elements at the >>>>> area it should be displayed instead? >>>>> >>>> >>>> Place invisible elements on top with absolute positioning? That seems >>>> error prone + you'd constantly have to change the DOM >>>> Also, the focus area is not always rectangular. For an example see >>>> http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >>>> (You will need chorme canary or latest firefox nightly with focusrings >>>> turned on) >>>> >>> >>> I see. That's a good use case. >>> >>> Also, the spec seems to indicate that the physical (rendered) >>>>>>> position of an element can change dynamically without UA being notified. >>>>>>> How are ATs supposed to inform users of the ordering of those >>>>>>> focusable elements? >>>>>>> >>>>>> >>>>>> I'm unsure I follow. Can you elaborate? >>>>>> >>>>> >>>>> How are ATs supposed to know the visual ordering of elements if >>>>> authors are only updating elements' positions by calling >>>>> drawSystemFocusRing when they are focused is my question. To put it >>>>> another way, ATs need to know where elements appear in order to let user >>>>> move the focus onto those elements. >>>>> >>>> >>>> What is an AT? :-) >>>> You don't call drawSystemFocusRing when an element is focused. You >>>> *always* call it and if it is focused, a ring will be drawn. In all cases, >>>> the accessibility software is notified of the area. >>>> >>> >>> WAT. Why is this function called drawSystemFocusRing if it doesn't draw >>> anything? I completely misunderstood the API because of its misleading >>> name. Can we please rename the function? e.g. defineSystemFocusableArea. >>> >>> I strongly object to the proposed name. >>> >> >> No, the function will draw the ring, but only if the element is focused. >> People have gone over the name multiple times and this seems to be the >> one that's hated the least :-( >> > > Only if it's focused right? But the point of this function is that > defining area for every focusable element upfront. Then the name of the > function should reflect that semantics. The fact it draws the focus ring > synchronously sometimes is almost a side-effect. > I agree. This is why the feature is still behind a flag in chrome and firefox and on the at-risk list for Canvas. Dominic and I want to clarify the text and possible come up with better names. By implementing it, we can start to see the problems with the current wording. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Thu, Oct 10, 2013 at 7:07 PM, Ryosuke Niwa wrote: > The spec. text is also misleading in saying that > > The drawSystemFocusRing(element) method, when invoked, must run the > following steps: > > If I understood your reply correctly, these are steps that need to be ran > continuously? Or is it that steps 2 & 3 must run upon the currently > focused element being changed. The specification needs to revised to > clarify this. > I think non-normative text or a note could be added to make this more clear. In general, the function should be called when the focus changes or the element is relocated and the canvas should be redrawn. > As is, the specification reads as if the author needs to repaint and call > drawSystemFocusRing upon focus change. > That is correct and what should happen. > > - R. Niwa > > > On Thu, Oct 10, 2013 at 7:02 PM, Ryosuke Niwa wrote: > >> On Thu, Oct 10, 2013 at 6:56 PM, Rik Cabanier wrote: >> >>> On Thu, Oct 10, 2013 at 6:08 PM, Ryosuke Niwa wrote: >>> >>>> On Thu, Oct 10, 2013 at 1:35 PM, Rik Cabanier wrote: >>>>> >>>>> Support (behind runtime flags) has landed in: >>>>>>> - Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=540456 >>>>>>> - chrome: https://code.google.com/p/chromium/issues/detail?id=261998 >>>>>>> >>>>>>> Focus rings associate elements that are in a canvas tag with areas >>>>>>> of the canvas. >>>>>>> If the user tabs into the hidden element or the accessibility >>>>>>> software selects them, these methods will draw or let the author draw >>>>>>> the >>>>>>> focus rings. >>>>>>> >>>>>> >>>>>> How does this API address this use case? It seems like each Web app >>>>>> needs to explicitly opt-in and manually draw focus ring? >>>>>> >>>>> >>>>> That is correct. This is code that the canvas developer needs to >>>>> implement. >>>>> >>>>> I'm not sure if that's a good accessibility API given that many >>>>>> authors don't even use most basic accessibility feature such as ARIA >>>>>> roles. >>>>>> >>>>> >>>>> There's not much we can do about this. However, for authors that DO >>>>> want to provide this, there's is currently no way to provide accessibility >>>>> for canvas. >>>>> >>>>> >>>>>> >>>>>> e.g. why can't UA automatically draw focus ring on top of the canvas? >>>>>> >>>>> >>>>> The problem is that the UA doesn't know what part of the canvas area >>>>> corresponds with the hidden element. This API is designed to make that >>>>> association >>>>> >>>> >>>> Why can't authors provide that information by placing elements at the >>>> area it should be displayed instead? >>>> >>> >>> Place invisible elements on top with absolute positioning? That seems >>> error prone + you'd constantly have to change the DOM >>> Also, the focus area is not always rectangular. For an example see >>> http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >>> (You will need chorme canary or latest firefox nightly with focusrings >>> turned on) >>> >> >> I see. That's a good use case. >> >> Also, the spec seems to indicate that the physical (rendered) position >>>>>> of an element can change dynamically without UA being notified. >>>>>> How are ATs supposed to inform users of the ordering of those >>>>>> focusable elements? >>>>>> >>>>> >>>>> I'm unsure I follow. Can you elaborate? >>>>> >>>> >>>> How are ATs supposed to know the visual ordering of elements if authors >>>> are only updating elements' positions by calling drawSystemFocusRing when >>>> they are focused is my question. To put it another way, ATs need to know >>>> where elements appear in order to let user move the focus onto those >>>> elements. >>>> >>> >>> What is an AT? :-) >>> You don't call drawSystemFocusRing when an element is focused. You >>> *always* call it and if it is focused, a ring will be drawn. In all cases, >>> the accessibility software is notified of the area. >>> >> >> WAT. Why is this function called drawSystemFocusRing if it doesn't draw >> anything? I completely misunderstood the API because of its misleading >> name. Can we please rename the function? e.g. defineSystemFocusableArea. >> >> I strongly object to the proposed name. >> >> - R. Niwa >> >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Thu, Oct 10, 2013 at 7:02 PM, Ryosuke Niwa wrote: > On Thu, Oct 10, 2013 at 6:56 PM, Rik Cabanier wrote: > >> On Thu, Oct 10, 2013 at 6:08 PM, Ryosuke Niwa wrote: >> >>> On Thu, Oct 10, 2013 at 1:35 PM, Rik Cabanier wrote: >>>> >>>> Support (behind runtime flags) has landed in: >>>>>> - Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=540456 >>>>>> - chrome: https://code.google.com/p/chromium/issues/detail?id=261998 >>>>>> >>>>>> Focus rings associate elements that are in a canvas tag with areas of >>>>>> the canvas. >>>>>> If the user tabs into the hidden element or the accessibility >>>>>> software selects them, these methods will draw or let the author draw the >>>>>> focus rings. >>>>>> >>>>> >>>>> How does this API address this use case? It seems like each Web app >>>>> needs to explicitly opt-in and manually draw focus ring? >>>>> >>>> >>>> That is correct. This is code that the canvas developer needs to >>>> implement. >>>> >>>> I'm not sure if that's a good accessibility API given that many >>>>> authors don't even use most basic accessibility feature such as ARIA >>>>> roles. >>>>> >>>> >>>> There's not much we can do about this. However, for authors that DO >>>> want to provide this, there's is currently no way to provide accessibility >>>> for canvas. >>>> >>>> >>>>> >>>>> e.g. why can't UA automatically draw focus ring on top of the canvas? >>>>> >>>> >>>> The problem is that the UA doesn't know what part of the canvas area >>>> corresponds with the hidden element. This API is designed to make that >>>> association >>>> >>> >>> Why can't authors provide that information by placing elements at the >>> area it should be displayed instead? >>> >> >> Place invisible elements on top with absolute positioning? That seems >> error prone + you'd constantly have to change the DOM >> Also, the focus area is not always rectangular. For an example see >> http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >> (You will need chorme canary or latest firefox nightly with focusrings >> turned on) >> > > I see. That's a good use case. > > Also, the spec seems to indicate that the physical (rendered) position >>>>> of an element can change dynamically without UA being notified. >>>>> How are ATs supposed to inform users of the ordering of those >>>>> focusable elements? >>>>> >>>> >>>> I'm unsure I follow. Can you elaborate? >>>> >>> >>> How are ATs supposed to know the visual ordering of elements if authors >>> are only updating elements' positions by calling drawSystemFocusRing when >>> they are focused is my question. To put it another way, ATs need to know >>> where elements appear in order to let user move the focus onto those >>> elements. >>> >> >> What is an AT? :-) >> You don't call drawSystemFocusRing when an element is focused. You >> *always* call it and if it is focused, a ring will be drawn. In all cases, >> the accessibility software is notified of the area. >> > > WAT. Why is this function called drawSystemFocusRing if it doesn't draw > anything? I completely misunderstood the API because of its misleading > name. Can we please rename the function? e.g. defineSystemFocusableArea. > > I strongly object to the proposed name. > No, the function will draw the ring, but only if the element is focused. People have gone over the name multiple times and this seems to be the one that's hated the least :-( ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Thu, Oct 10, 2013 at 6:08 PM, Ryosuke Niwa wrote: > On Thu, Oct 10, 2013 at 1:35 PM, Rik Cabanier wrote: >> >> Support (behind runtime flags) has landed in: >>>> - Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=540456 >>>> - chrome: https://code.google.com/p/chromium/issues/detail?id=261998 >>>> >>>> Focus rings associate elements that are in a canvas tag with areas of >>>> the canvas. >>>> If the user tabs into the hidden element or the accessibility software >>>> selects them, these methods will draw or let the author draw the focus >>>> rings. >>>> >>> >>> How does this API address this use case? It seems like each Web app >>> needs to explicitly opt-in and manually draw focus ring? >>> >> >> That is correct. This is code that the canvas developer needs to >> implement. >> >> I'm not sure if that's a good accessibility API given that many authors >>> don't even use most basic accessibility feature such as ARIA roles. >>> >> >> There's not much we can do about this. However, for authors that DO want >> to provide this, there's is currently no way to provide accessibility for >> canvas. >> >> >>> >>> e.g. why can't UA automatically draw focus ring on top of the canvas? >>> >> >> The problem is that the UA doesn't know what part of the canvas area >> corresponds with the hidden element. This API is designed to make that >> association >> > > Why can't authors provide that information by placing elements at the area > it should be displayed instead? > Place invisible elements on top with absolute positioning? That seems error prone + you'd constantly have to change the DOM Also, the focus area is not always rectangular. For an example see http://dmazzoni-google.github.io/canvas-focus-ring-demo/ (You will need chorme canary or latest firefox nightly with focusrings turned on) > > >> Also, the spec seems to indicate that the physical (rendered) position >>> of an element can change dynamically without UA being notified. >>> How are ATs supposed to inform users of the ordering of those focusable >>> elements? >>> >> >> I'm unsure I follow. Can you elaborate? >> > > How are ATs supposed to know the visual ordering of elements if authors > are only updating elements' positions by calling drawSystemFocusRing when > they are focused is my question. To put it another way, ATs need to know > where elements appear in order to let user move the focus onto those > elements. > What is an AT? :-) You don't call drawSystemFocusRing when an element is focused. You *always* call it and if it is focused, a ring will be drawn. In all cases, the accessibility software is notified of the area. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Thu, Oct 10, 2013 at 5:49 PM, Chris Fleizach wrote: > > On Oct 10, 2013, at 1:35 PM, Rik Cabanier wrote: > > > > > On Thu, Oct 10, 2013 at 1:14 PM, Ryosuke Niwa wrote: > >> On Wed, Oct 9, 2013 at 9:08 PM, Rik Cabanier wrote: >> >>> I'd like to add for focus rings. They are currently specified in the w3c >>> and whatwg canvas specs: >>> >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusring >>> http://www.w3.org/TR/2dcontext/#dom-context-2d-drawsystemfocusring >>> >> >> Could you point us to the list of use cases or the whatwg/w3c thread >> where the discussion took place? >> > > Rich should be able to point you to where those are posted since he was > the main contributor. (You can also do a search for "canvas focus rings" to > find many email threads on whatwg) > > >> >> Support (behind runtime flags) has landed in: >>> - Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=540456 >>> - chrome: https://code.google.com/p/chromium/issues/detail?id=261998 >>> >>> Focus rings associate elements that are in a canvas tag with areas of >>> the canvas. >>> If the user tabs into the hidden element or the accessibility software >>> selects them, these methods will draw or let the author draw the focus >>> rings. >>> >> >> How does this API address this use case? It seems like each Web app >> needs to explicitly opt-in and manually draw focus ring? >> > > That is correct. This is code that the canvas developer needs to implement. > > >> I'm not sure if that's a good accessibility API given that many authors >> don't even use most basic accessibility feature such as ARIA roles. >> > > There's not much we can do about this. However, for authors that DO want > to provide this, there's is currently no way to provide accessibility for > canvas. > > >> >> e.g. why can't UA automatically draw focus ring on top of the canvas? >> > > The problem is that the UA doesn't know what part of the canvas area > corresponds with the hidden element. This API is designed to make that > association > > > It seems this API will draw an area that corresponds to a hidden element. > Is there a way to provide actual information about the element? (label, > role, etc) > The UA knows what element is focused so it can provide the accessibility software (such as voiceover) with that information. > > > > >> >> Also, the spec seems to indicate that the physical (rendered) position of >> an element can change dynamically without UA being notified. >> How are ATs supposed to inform users of the ordering of those focusable >> elements? >> > > I'm unsure I follow. Can you elaborate? > > >> >> I created a patch (https://bugs.webkit.org/show_bug.cgi?id=122177) but >>> it needs more tests. >>> Also, should I implement it behind a runtime flags? >>> >> >> I definitely would like to see a build flag around it. >> > > OK. I will do so. > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for focus rings in Canvas 2d
On Thu, Oct 10, 2013 at 1:14 PM, Ryosuke Niwa wrote: > On Wed, Oct 9, 2013 at 9:08 PM, Rik Cabanier wrote: > >> I'd like to add for focus rings. They are currently specified in the w3c >> and whatwg canvas specs: >> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusring >> http://www.w3.org/TR/2dcontext/#dom-context-2d-drawsystemfocusring >> > > Could you point us to the list of use cases or the whatwg/w3c thread where > the discussion took place? > Rich should be able to point you to where those are posted since he was the main contributor. (You can also do a search for "canvas focus rings" to find many email threads on whatwg) > > Support (behind runtime flags) has landed in: >> - Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=540456 >> - chrome: https://code.google.com/p/chromium/issues/detail?id=261998 >> >> Focus rings associate elements that are in a canvas tag with areas of the >> canvas. >> If the user tabs into the hidden element or the accessibility software >> selects them, these methods will draw or let the author draw the focus >> rings. >> > > How does this API address this use case? It seems like each Web app needs > to explicitly opt-in and manually draw focus ring? > That is correct. This is code that the canvas developer needs to implement. > I'm not sure if that's a good accessibility API given that many authors > don't even use most basic accessibility feature such as ARIA roles. > There's not much we can do about this. However, for authors that DO want to provide this, there's is currently no way to provide accessibility for canvas. > > e.g. why can't UA automatically draw focus ring on top of the canvas? > The problem is that the UA doesn't know what part of the canvas area corresponds with the hidden element. This API is designed to make that association > > Also, the spec seems to indicate that the physical (rendered) position of > an element can change dynamically without UA being notified. > How are ATs supposed to inform users of the ordering of those focusable > elements? > I'm unsure I follow. Can you elaborate? > > I created a patch (https://bugs.webkit.org/show_bug.cgi?id=122177) but >> it needs more tests. >> Also, should I implement it behind a runtime flags? >> > > I definitely would like to see a build flag around it. > OK. I will do so. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal: Add support for focus rings in Canvas 2d
All, I'd like to add for focus rings. They are currently specified in the w3c and whatwg canvas specs: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusring http://www.w3.org/TR/2dcontext/#dom-context-2d-drawsystemfocusring Support (behind runtime flags) has landed in: - Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=540456 - chrome: https://code.google.com/p/chromium/issues/detail?id=261998 Focus rings associate elements that are in a canvas tag with areas of the canvas. If the user tabs into the hidden element or the accessibility software selects them, these methods will draw or let the author draw the focus rings. I created a patch (https://bugs.webkit.org/show_bug.cgi?id=122177) but it needs more tests. Also, should I implement it behind a runtime flags? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add support for Promises
That sounds like a great idea! The blink people are running into a bunch of issues by implementing them on the C++ side as opposed to inside the VM. Implement them in JavaScript seems like the right approach. On Fri, Aug 23, 2013 at 11:32 AM, Sam Weinig wrote: > Hey WebKittens, > > I’d like to add support for Promises. Promises are currently specified in > the DOM Living Standard (http://dom.spec.whatwg.org/#promises) but will > probably be moved to an ECMAScript standard at some point in the future. > As such, I plan to implement them in JavaScriptCore. > > The main motivation for adding Promises is that many upcoming specs have > them as a dependency, including WebCrypto ( > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html), > the updated FileSystem API ( > http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0071.html) > and others. > > Thoughts? > > -Sam > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
Things are not that bad. (See Shadow DOM for instance where people begged for it to become a standard) You should definitely write something up and have a working prototype that demonstrates how your solution improves performance, cleaner implementations, etc. You will also have to prove that this won't introduce security issues. Any new feature will face a lot of scrutiny since it impacts everything that runs a web browser so be prepared for negative feedback. You will spend much more time replying on mailing list than actually implementing it. :-) Even if your proposal fails, it will still be used as a reference for a future solution. On Sat, Apr 13, 2013 at 12:35 PM, Dirk Pranke wrote: > > On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo wrote: > >> >> On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote: >> >> Perhaps we can come up with some JS API for shared memory & lock and >> propose it in TC39 or WebApps WG? >> >> >> I think that would be wonderful. Anyone else interested? >> >> > Feel free to write something up, but as I said before, I suspect any such > proposal is DOA in either group. If you wanted to get something adopted > here, I think you would have to build something, ship it, and then have it > become so successful that the standards groups would be forced to > reconsider their positions. > > -- Dirk > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
On Fri, Apr 12, 2013 at 10:34 PM, Filip Pizlo wrote: > > On Apr 12, 2013, at 9:46 PM, Rik Cabanier wrote: > > > > On Fri, Apr 12, 2013 at 9:39 PM, Zoltan Herczeg > wrote: > >> > A message passing model a la Web Workers has some advantages compared to >> > threads with shared mutable state and locks: >> > - No possibility of deadlock >> > - No possibility of corrupting data structures due to races >> > - No performance penalty from correctly supporting fine-grained >> concurrent >> > access to arbitrary mutable objects >> > >> > The first is particularly important as you really do not want the web >> > page's UI thread to lock up, even if the page itself is not making >> > progress. >> > >> > I believe message passing as a concurrent programming model is much less >> > prone to severe errors than shared mutable state + locking. I think you >> > have to be super smart to even have a chance of using shared mutable >> state >> > correctly. That being said, I am not sure Web Workers as they exist >> today >> > are the best possible form of message passing. >> >> We tried to use WebWorkers for parallel computation, but in their current >> form, they are useless. We also searched for other Worker demos on the >> net, and all of them were slower with workers. I suspect ParallelArray >> will not help either. >> > > Have you tried pdf.js? That uses workers for various operations. > There's an option to turn off workers and it makes pages display slower. > > > Pdf.js is really cool. But I agree with Zoltan's general assessment of > workers: they are not easy to use. Just because pdf.js uses them doesn't > mean we can't do better. > I completely agree. Not only are they hard; apparently it's unspecified what API's are available to them. [1] I was just replying to his point that all uses of workers make things slower. 1: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0054.html > >> The problem is not producing messages, but receiving and processing them >> on the other side. Why? Because that involves JS. Noone will use JS to >> search prime numbers, they want to control the UI (animations, image >> generation, physics, etc.). >> >> Imho Workers need an API, which can be used to set (and perhaps get) >> properties without calling JS. Especially timed set (the change should be >> happen in a given time in the future). Very important for smooth >> animations. These properties must be constants: numbers, strings, RGBA >> arrays, etc. When we set dozens of properties, the extra cost on the UI >> side should be minimal. > > > What do you mean here? Maybe some pseudocode will make it clear for me. > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
On Fri, Apr 12, 2013 at 9:39 PM, Zoltan Herczeg wrote: > > A message passing model a la Web Workers has some advantages compared to > > threads with shared mutable state and locks: > > - No possibility of deadlock > > - No possibility of corrupting data structures due to races > > - No performance penalty from correctly supporting fine-grained > concurrent > > access to arbitrary mutable objects > > > > The first is particularly important as you really do not want the web > > page's UI thread to lock up, even if the page itself is not making > > progress. > > > > I believe message passing as a concurrent programming model is much less > > prone to severe errors than shared mutable state + locking. I think you > > have to be super smart to even have a chance of using shared mutable > state > > correctly. That being said, I am not sure Web Workers as they exist today > > are the best possible form of message passing. > > We tried to use WebWorkers for parallel computation, but in their current > form, they are useless. We also searched for other Worker demos on the > net, and all of them were slower with workers. I suspect ParallelArray > will not help either. > Have you tried pdf.js? That uses workers for various operations. There's an option to turn off workers and it makes pages display slower. > > The problem is not producing messages, but receiving and processing them > on the other side. Why? Because that involves JS. Noone will use JS to > search prime numbers, they want to control the UI (animations, image > generation, physics, etc.). > > Imho Workers need an API, which can be used to set (and perhaps get) > properties without calling JS. Especially timed set (the change should be > happen in a given time in the future). Very important for smooth > animations. These properties must be constants: numbers, strings, RGBA > arrays, etc. When we set dozens of properties, the extra cost on the UI > side should be minimal. What do you mean here? Maybe some pseudocode will make it clear for me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: "opaque" attribute
globalAlpha will still work but will always composite with an opaque
backdrop (which is black by default)
On Wed, Mar 13, 2013 at 3:25 PM, Elliott Sprehn wrote:
> alpha:false is super confusing to me. It makes it sound as though all
> draw*() operations that use an alpha channel will fail... does globalAlpha
> still work?
>
> It's sad that WebGL picked such a generic name that isn't about all
> "alpha" related things.
>
>
> On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier wrote:
>
>> The main reason for this feature is to enhance performance of canvas
>> operations.
>> Are we certain that this will always be the case? For instance, is google
>> going to make certain that the cairo and core graphics backends don't slow
>> down?
>>
>> Rik
>>
>>
>> On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones wrote:
>>
>>> I think "opaque" vs. "alpha: false" is a matter of opinion. The
>>> functionality doesn't change, regardless of what you call it.
>>>
>>> I agree with Gregg that this really should be implemented to reflect the
>>> functionality that WebGL already has. Wether 2D or 3D, there's a lot of
>>> common ground between the various canvas contexts and it doesn't make much
>>> sense to reinvent the wheel when one context type has already implemented
>>> the functionality.
>>>
>>> --Brandon
>>>
>>>
>>> On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak wrote:
>>>
>>>>
>>>> An attribute on the canvas element would presumably be equally
>>>> applicable to all contexts. Is there a reason that it's better to have
>>>> opaqueness specified at context creation time instead of on the canvas?
>>>> Also, I think "opaque" is easier to understand than "alpha: false".
>>>>
>>>> - Maciej
>>>>
>>>> On Mar 13, 2013, at 9:57 AM, Gregg Tavares wrote:
>>>>
>>>> It would be nice if this was the same as WebGL instead of different.
>>>> Especially because 2d canvas and WebGL need to inter-operate in the near
>>>> future.
>>>>
>>>> In WebGL to create a canvas with no alpha (an opaque canvas) you do this
>>>>
>>>>gl = canvas.getContext("experimental-webgl", { alpha: false });
>>>>
>>>> Why can't 2D canvas be this
>>>>
>>>>ctx = canvas.getContext("2d", {alpha: false});
>>>>
>>>> As for why this is important to be the same see the proposal for Canvas
>>>> in Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
>>>>
>>>> In that proposal the "backingstore" of a canvas can be moved to/from a
>>>> worker. That solution may or many not be the final solution but it points
>>>> out that whatever solution is chosen we need the solution to work for both
>>>> canvas 2d and WebGL and as such needs a common way to create backing stores
>>>> with no alpha.
>>>>
>>>>
>>>>
>>>> On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze
>>>> wrote:
>>>>
>>>>> This is a very long thread and I did not see any conclusions or
>>>>> agreement on this thread. Can you summarize the topic and the status on
>>>>> the
>>>>> acceptance level please?
>>>>>
>>>>> Greetings,
>>>>> Dirk
>>>>>
>>>>> On Mar 13, 2013, at 9:15 AM, Stephen White
>>>>> wrote:
>>>>>
>>>>> > Hi WebKittens,
>>>>> >
>>>>> > I'm planning to implement the canvas "opaque" attribute, as proposed
>>>>> here:
>>>>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html
>>>>> .
>>>>> >
>>>>> > This is an attribute that causes the allocation of an opaque backing
>>>>> store for , allowing optimizations at the time the canvas is
>>>>> composited into the page, such as disabling blending and culling obscured
>>>>> content. It is based on the moz-opaque attribute currently shipping in
>>>>> Firefox.
>>>>> >
>>>>> > I'll be placing the feature behind the build-time flag
>>>>> ENABLE(OPAQUE_CANVAS).
>>>>> >
>>>>> > Let me know if you have any comments or conce
Re: [webkit-dev] New web-facing canvas feature: "opaque" attribute
The main reason for this feature is to enhance performance of canvas
operations.
Are we certain that this will always be the case? For instance, is google
going to make certain that the cairo and core graphics backends don't slow
down?
Rik
On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones wrote:
> I think "opaque" vs. "alpha: false" is a matter of opinion. The
> functionality doesn't change, regardless of what you call it.
>
> I agree with Gregg that this really should be implemented to reflect the
> functionality that WebGL already has. Wether 2D or 3D, there's a lot of
> common ground between the various canvas contexts and it doesn't make much
> sense to reinvent the wheel when one context type has already implemented
> the functionality.
>
> --Brandon
>
>
> On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak wrote:
>
>>
>> An attribute on the canvas element would presumably be equally applicable
>> to all contexts. Is there a reason that it's better to have opaqueness
>> specified at context creation time instead of on the canvas? Also, I think
>> "opaque" is easier to understand than "alpha: false".
>>
>> - Maciej
>>
>> On Mar 13, 2013, at 9:57 AM, Gregg Tavares wrote:
>>
>> It would be nice if this was the same as WebGL instead of different.
>> Especially because 2d canvas and WebGL need to inter-operate in the near
>> future.
>>
>> In WebGL to create a canvas with no alpha (an opaque canvas) you do this
>>
>>gl = canvas.getContext("experimental-webgl", { alpha: false });
>>
>> Why can't 2D canvas be this
>>
>>ctx = canvas.getContext("2d", {alpha: false});
>>
>> As for why this is important to be the same see the proposal for Canvas
>> in Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
>>
>> In that proposal the "backingstore" of a canvas can be moved to/from a
>> worker. That solution may or many not be the final solution but it points
>> out that whatever solution is chosen we need the solution to work for both
>> canvas 2d and WebGL and as such needs a common way to create backing stores
>> with no alpha.
>>
>>
>>
>> On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze wrote:
>>
>>> This is a very long thread and I did not see any conclusions or
>>> agreement on this thread. Can you summarize the topic and the status on the
>>> acceptance level please?
>>>
>>> Greetings,
>>> Dirk
>>>
>>> On Mar 13, 2013, at 9:15 AM, Stephen White
>>> wrote:
>>>
>>> > Hi WebKittens,
>>> >
>>> > I'm planning to implement the canvas "opaque" attribute, as proposed
>>> here:
>>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html
>>> .
>>> >
>>> > This is an attribute that causes the allocation of an opaque backing
>>> store for , allowing optimizations at the time the canvas is
>>> composited into the page, such as disabling blending and culling obscured
>>> content. It is based on the moz-opaque attribute currently shipping in
>>> Firefox.
>>> >
>>> > I'll be placing the feature behind the build-time flag
>>> ENABLE(OPAQUE_CANVAS).
>>> >
>>> > Let me know if you have any comments or concerns.
>>> >
>>> > Stephen
>>> > ___
>>> > webkit-dev mailing list
>>> > webkit-dev@lists.webkit.org
>>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] css: rotateY(90) with perspective()
Those render exactly the same for me in chrome and ff: http://jsfiddle.net/8pyDK/ What OS are you testing on? It seems that the perspective is ignored. On Tue, Feb 12, 2013 at 2:18 PM, Marcin Szamotulski wrote: > I opened a new bug report: > https://bugs.webkit.org/show_bug.cgi?id=109613 > > Best, > Marcin > > On 12:07 Tue 12 Feb , Levi Weintraub wrote: > > Either way, I'd suggest you take this conversation to a specific bug > report > > :) > > > > > > On Tue, Feb 12, 2013 at 11:49 AM, Shawn Singh >wrote: > > > > > Hi Marcin, > > > > > > I wonder if you might accidentally have a "perspective-origin" set > > > differently? Or maybe there is something in your code where window > size > > > that affects how the transforms appear? Maybe you can attach a reduced > > > simple example of the difference you're seeing? I just whipped up the > > > following example, which renders almost exactly the same geometry on > both > > > Firefox and tip-of-tree Chromium. > > > > > > > > > > > > HELLO WORLD > > > > > > > > > > > > > > > Changing the rotateY to use 90deg makes the layer disappear for both > > > Firefox and Chromium, too. > > > > > > ~Shawn > > > > > > > > > > > > > > > On Tue, Feb 12, 2013 at 9:53 AM, Dana Jansens > wrote: > > > > > >> +shawnsingh > > >> > > >> > > >> On Tue, Feb 12, 2013 at 9:22 AM, Marcin Szamotulski < > msza...@gmail.com>wrote: > > >> > > >>> Dear WebKit-Dev, > > >>> > > >>> I found an interesting difference between implementation of css 3d > > >>> transforms in Gecko (FireFox) and Chromium (WebKit). In Gecko, the > > >>> following css rule: > > >>> > > >>> tranform: perspective(500px) rotateY(90) > > >>> > > >>> rotates an element (let say an image) so that it is perpendicular to > the > > >>> viewer, i.e. it shows the side of the element - hence nothing is > printed > > >>> to the screen, since html elements have no depth. While in WebKit > based > > >>> browsers (I have tested this in both Chromium and surf from > suckles.org) > > >>> the elements is shown at an angle: both rotations (Gecko & WebKit) > have > > >>> the same axis (the vertical screen directions). Testing different > > >>> angles I have found that I need to use rotateY(107deg), but this > might > > >>> depend on the perspective. The reason for this is that WebKit and > > >>> Gecko are computing 3d view in a different way. The additional minor > > >>> difference is that rotateY(30deg) in Gecko turns an element 30deg to > the > > >>> right while in WebKit it rotates to the left (with a different 3d > view). > > >>> The reason I found it is because I try to make an animation which > turns > > >>> a picture around 180deg showing a new picture on the other side, and > > >>> I wanted to change the picture in the middle (90deg). This works for > > >>> Gecko but for WebKit I need to know how to compute the angle at which > > >>> the element (image) is perpendicular to the view source (showing its > > >>> side to the viewer). Can somebody point me how the 3d rotationY with > > >>> a given perspective is calculated so I can make the necessary > > >>> converstion. > > >>> > > >>> Best regards, > > >>> Marcin Szamotulski > > >>> ___ > > >>> webkit-dev mailing list > > >>> webkit-dev@lists.webkit.org > > >>> https://lists.webkit.org/mailman/listinfo/webkit-dev > > >>> > > >> > > >> > > > > > > ___ > > > webkit-dev mailing list > > > webkit-dev@lists.webkit.org > > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > > > > > > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to background images
On Fri, Feb 1, 2013 at 1:08 PM, Dirk Schulze wrote: > > On Feb 2, 2013, at 8:01 AM, Benjamin Poulain wrote: > > > On Fri, Feb 1, 2013 at 12:44 PM, Rik Cabanier > wrote: > > background-image: url(a.png), url(b.png); > > -webkit-background-blend-mode: screen, screen; > > > > Out of curiosity: > > > > I am probably way too late for the party, but why not blend > surface-to-surface? E.g. > > background-image: blend(url(foo.png), url(bar.png), difference). > > > > This is in order to easily stack them: > > background-image: blend(blend(url(foo.png), url(bar.png), > difference), url(giraffe.gif), screen). > > I like the idea, but it has the big disadvantage that you can not repeat > an image, change origin and size before blending with the next layer. > True. This feels more like a filter where you pull different sources in. > > > > > Although, maybe we don't want that as it could get more difficult to > optimize... > > > > Benjamin > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to background images
you will be able to do this by using the fully featured 'mix-blend-mode' property [1]. for instance, if you want 2 images to blend with each other, but not with their background: <- anything that creates a stacking context 1: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#mix-blend-mode On Fri, Feb 1, 2013 at 1:01 PM, Benjamin Poulain wrote: > On Fri, Feb 1, 2013 at 12:44 PM, Rik Cabanier wrote: > >> background-image: url(a.png), url(b.png); >> -webkit-background-blend-mode: screen, screen; >> >> > Out of curiosity: > > I am probably way too late for the party, but why not blend > surface-to-surface? E.g. > background-image: blend(url(foo.png), url(bar.png), difference). > > This is in order to easily stack them: > background-image: blend(blend(url(foo.png), url(bar.png), difference), > url(giraffe.gif), screen). > > Although, maybe we don't want that as it could get more difficult to > optimize... > > Benjamin > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to background images
Sure!
For instance:
.example {
width: 500px;
height: 500px;
background-image: url(a.png), url(b.png);
-webkit-background-blend-mode: screen, screen;
}
The in this document contains 2 background images. The
'-webkit-background-blend-mode' property assigns a blending mode to each of
them.
It works very similar to '-webkit-background-composite' [1]
The images blend with each other and their existing backdrop as stated by
the CSS drawing model [2].
This feature will give designers the ability to blend layers of images
together much like they do in graphics applications [3]
Rik
1: https://www.webkit.org/blog/181/css-masks/
2: http://www.w3.org/TR/CSS21/zindex.html
3: see *http://www.youtube.com/watch?v=diJzT-sHizg* for links to tutorials.
On Fri, Feb 1, 2013 at 12:09 PM, Dirk Schulze wrote:
> Hi Rik,
>
> Can you just add an example for the better understanding please?
>
> Greetings,
> Dirk
>
> On Feb 2, 2013, at 6:43 AM, Rik Cabanier wrote:
>
> > Hi,
> >
> > I'd like to add support for blending of background images.
> > The spec for this feature can be found here:
> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#background-blend-mode
> >
> > The implementation will be tracked by a meta bug:
> https://bugs.webkit.org/show_bug.cgi?id=108546
> >
> > Please let me know of any concerns.
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding blending mode to background images
Hi, I'd like to add support for blending of background images. The spec for this feature can be found here: * https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#background-blend-mode * The implementation will be tracked by a meta bug: * https://bugs.webkit.org/show_bug.cgi?id=108546* Please let me know of any concerns. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Fwd: Proposal: Add CanvasRenderingContext2D.fillRule with "nonzero" (default) and "evenodd" options
After a discussion the mailing list, we settled on the following syntax:
1. create an enum for the winding rule:
enum CanvasWindingRule { "nonzero", "evenodd" };
2. extend fill:
void fill(*optional CanvasWindingRule w = "nonzero"*);
3. extend clip:
void clip(*optional CanvasWindingRule w = "nonzero"*);
4. extend isPointInPath:
boolean isPointInPath(unrestricted double x, unrestricted double y, *optional
CanvasWindingRule w = "nonzero"*);
This API is already submitted to mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=827053
I also have a patch that will implement this in WebKit too:
https://bugs.webkit.org/show_bug.cgi?id=106188
Please let me know if there are any objections.
Rik
On Wed, Jan 9, 2013 at 11:59 AM, Tab Atkins Jr. wrote:
> On Wed, Jan 9, 2013 at 11:42 AM, Rik Cabanier wrote:
> > Do people have an opinion on a boolean value vs an enum?
> > A boolean value is slightly faster to execute and type while an enum is
> > more descriptive.
> >
> > So far, canvas has not used enum values before.
>
> I strongly prefer enums for cases where it's not a simple yes/no, and
> this clearly qualifies.
>
> (I also prefer enums generally even when this is true, but that's my
> CSS experience talking, where we have a history of changing things
> that were once booleans into multi-state when people ask for more
> features later.)
>
> ~TJ
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, Jan 4, 2013 at 8:04 PM, Dirk Schulze wrote: > > > On Jan 4, 2013, at 7:28 PM, "Rik Cabanier" wrote: > > > > On Fri, Jan 4, 2013 at 5:42 PM, Dirk Schulze wrote: > >> >> On Jan 4, 2013, at 5:24 PM, Rik Cabanier wrote: >> >> > >> > >> > On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson wrote: >> > On Fri, 4 Jan 2013, Rik Cabanier wrote: >> > > >> > > I think this feature was rushed in the spec. >> > >> > The specing is usually the first step. You can't rush to spec. :-) >> > >> > In this particular case, though, it was the third or fourth step. The >> > discussion has been open since June 2011. It's not like people didn't >> have >> > time to comment. It's been shipping in a browser for over a year. >> > >> > Any solution we come up with to the issues that were raised regarding >> Path >> > will almost certainly be done in a way that builds on context.fillRule, >> > not in a way that removes context.fillRule. >> > >> > I was not aware of that discussion. >> > There are good reasons to make the fill rule part of the fill operation >> itself. It does not make sense in the graphic state. >> > >> > How about EOClip? That is a construct that is far more used than >> eofill. Will that get its own parameter too? >> >> It will use the same property, since there is no difference. That is why >> the name could be a bit misleading. windingRule would be a bit more >> independent of the fill operation. >> > > That is a problem. Now you will have to set the parameter before the clip > and set it back again right after (since you can't use save/restore since > it blows away the clip) > > I don't see the problem here. That is how canvas works currently. fill() > and clip() use the currentPath. Seems to be more natural to use the > property then. > With the property, you will have to always be sure that it is set to the value you expect. So you either set it before every draw or clip, or you only set it before doing an eoclip or eofill and then set it back. > > > >> >> > How about the interaction of stroking and this parameter (if you follow >> the spec's wording for stroking)? >> >> This needs to change as well to match the new behavior. This is more a >> specification problem and no implementation problem. >> > > I agree. However, user agents didn't have to really think about this > before but they will have to in the future. Making it part of the state > will make it much more difficult to implement cleanly. > > > Not at all, as demonstrated with the patch. > in the *future*, when for example there is support for paths, this global flag will make it more difficult. (Paths will need to take winding into account if we want the regions to be useful) > > > >> >> > How about ispointinpath? Will that follow the winding rule in the >> graphic state? >> >> It would depend on the fillRule that you set on the context. >> >> > How about hit regions? How can you specify the winding there? >> >> This is a good point. But it depends if hit region will be implemented as >> specified. >> >> > >> > It's better to follow what almost every other graphics library has >> done: Add an EOFill and an EOClip. >> > I volunteer to add it to Mozilla if it helps. >> >> That is not fully correct. Just Qt and Skia make it explicitly on the >> Path object (which is not necessarily depending on the fill operation >> itself). CG does not bundle EOfill with a path, instead you set it during >> painting. Which is partly as done by the specification, with the exception >> that it is not part of the graphic state, but also not part of the path >> logic. > > > Core graphics has indeed no support for paths (just like the current > canvas implementations) > However, it does have 'CGContextEOClip' and 'CGContextEOFill' that works > on the current path which is what I propose we should do. > > No, because the path is already applied to the context. That makes the > property so natural and easy to implement. > yes, the current path is in the context, but not the winding rule. That is specified with 'CGContextEOClip' or 'CGContextEOFill'. To me, this makes eofill and eoclip a more natural implementation. > > > >> Cairo graphics has the fill rule as part of the graphic state IIRC. >> >> This discussion is a bit misplaced on webkit-dev. Could you continue it &g
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, Jan 4, 2013 at 5:42 PM, Dirk Schulze wrote: > > On Jan 4, 2013, at 5:24 PM, Rik Cabanier wrote: > > > > > > > On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson wrote: > > On Fri, 4 Jan 2013, Rik Cabanier wrote: > > > > > > I think this feature was rushed in the spec. > > > > The specing is usually the first step. You can't rush to spec. :-) > > > > In this particular case, though, it was the third or fourth step. The > > discussion has been open since June 2011. It's not like people didn't > have > > time to comment. It's been shipping in a browser for over a year. > > > > Any solution we come up with to the issues that were raised regarding > Path > > will almost certainly be done in a way that builds on context.fillRule, > > not in a way that removes context.fillRule. > > > > I was not aware of that discussion. > > There are good reasons to make the fill rule part of the fill operation > itself. It does not make sense in the graphic state. > > > > How about EOClip? That is a construct that is far more used than eofill. > Will that get its own parameter too? > > It will use the same property, since there is no difference. That is why > the name could be a bit misleading. windingRule would be a bit more > independent of the fill operation. > That is a problem. Now you will have to set the parameter before the clip and set it back again right after (since you can't use save/restore since it blows away the clip) > > > How about the interaction of stroking and this parameter (if you follow > the spec's wording for stroking)? > > This needs to change as well to match the new behavior. This is more a > specification problem and no implementation problem. > I agree. However, user agents didn't have to really think about this before but they will have to in the future. Making it part of the state will make it much more difficult to implement cleanly. > > > How about ispointinpath? Will that follow the winding rule in the > graphic state? > > It would depend on the fillRule that you set on the context. > > > How about hit regions? How can you specify the winding there? > > This is a good point. But it depends if hit region will be implemented as > specified. > > > > > It's better to follow what almost every other graphics library has done: > Add an EOFill and an EOClip. > > I volunteer to add it to Mozilla if it helps. > > That is not fully correct. Just Qt and Skia make it explicitly on the Path > object (which is not necessarily depending on the fill operation itself). > CG does not bundle EOfill with a path, instead you set it during painting. > Which is partly as done by the specification, with the exception that it is > not part of the graphic state, but also not part of the path logic. Core graphics has indeed no support for paths (just like the current canvas implementations) However, it does have 'CGContextEOClip' and 'CGContextEOFill' that works on the current path which is what I propose we should do. > Cairo graphics has the fill rule as part of the graphic state IIRC. > > This discussion is a bit misplaced on webkit-dev. Could you continue it on > the WHAT WG mailing list please? > I agree. However, if people didn't follow that mailing list, they would think that everything is sorted out since Ian emailed this list to say that it is in the spec . > > I would just agree with Rik here, that we should wait a bit more time > before implementing it in WebKit. Even if following the Firefox > implementation and the needs of PDF.js is a good reason for implementing as > suggested by the spec. > If it's for PDF, then a graphic state variable is not the way to go since PDF does not have this either. > > Greetings, > Dirk > > > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson wrote: > On Fri, 4 Jan 2013, Rik Cabanier wrote: > > > > I think this feature was rushed in the spec. > > The specing is usually the first step. You can't rush to spec. :-) > > In this particular case, though, it was the third or fourth step. The > discussion has been open since June 2011. It's not like people didn't have > time to comment. It's been shipping in a browser for over a year. > > Any solution we come up with to the issues that were raised regarding Path > will almost certainly be done in a way that builds on context.fillRule, > not in a way that removes context.fillRule. I was not aware of that discussion. There are good reasons to make the fill rule part of the fill operation itself. It does not make sense in the graphic state. How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? How about ispointinpath? Will that follow the winding rule in the graphic state? How about hit regions? How can you specify the winding there? It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. I volunteer to add it to Mozilla if it helps. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
I think this feature was rushed in the spec. Can we hold off submitting this until people have a chance to think it through? It seems innocent enough to make this part of the graphic state but I believe this is the wrong place (since no graphic library except cairo did it this way) and will give us problems down the line. On Thu, Jan 3, 2013 at 3:40 PM, Ian Hickson wrote: > On Wed, 2 Jan 2013, James Ascroft-Leigh wrote: > > > > There has been a proposal that a new property is added to the canvas 2D > > drawing context called fillRule with values "nonzero" (default) and > > "evenodd". This is compatible with the mozFillRule already implemented > > in Mozilla Firefox and would be on track to become a web standard. > > > > If you are interested in knowing more I suggest you start with the "bug" > > I raised and take a look at the patch. > > > > https://bugs.webkit.org/show_bug.cgi?id=105508 > > This is now in the spec. > http://whatwg.org/html/#dom-context-2d-fillrule > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Wed, Nov 14, 2012 at 5:55 PM, Maciej Stachowiak wrote: > > On Nov 14, 2012, at 5:19 PM, Rik Cabanier wrote: > > > > I send the question to the fx list. > Tab Atkins brought up that we could extend the 'globalCompositeOperator' > so it also takes a comma separate list of a blend and a compositing > operation. > > Calling: > > mycontext.globalCompositeOperator = 'multiply'; > > would be identical to: > > mycontext.globalCompositeOperator = 'multiply, source-over'; > > > This would make Canvas support blending and compositing and can be > implemented with no compatibility issues later. > > Does this ease your concern about the difference between Canvas and CSS? > > > That still seems inconsistent between canvas and CSS to me. CSS will have > two completely separate properties, not one that takes a comma-separated > list, right? Why is one attribute with a comma-separated list superior for > canvas but two properties are superior for CSS? > There have been requests to allow blending to be transitionable. This would be hard to accomplish with a comma separated list since it would imply that compositing is transitionable too. > > Other concerns: > - Taking a comma-separated list misleadingly implies that it can have an > arbitrary number of components in arbitrary order, which is not the case. > Maybe 'list' is not the best word. Other CSS properties have similar constructs (ie border-image [1]) > - Compared to having a separate property, this makes it hard to > feature-test whether blend modes are supported. > I don't believe that is the case. A user can set and read the property. If it comes back with the same value, he knows it's supported. > > I can join the fx list to discuss this directly if you think that would > help. > > Yes, that would be most helpful! thanks! Rik 1: http://www.w3.org/TR/2010/WD-css3-background-20100612/#the-border-image ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Wed, Nov 14, 2012 at 1:37 PM, Maciej Stachowiak wrote: > > On Nov 14, 2012, at 8:33 AM, Rik Cabanier wrote: > > > > On Tue, Nov 13, 2012 at 11:19 PM, Maciej Stachowiak wrote: > >> >> On Nov 13, 2012, at 4:43 PM, Rik Cabanier wrote: >> >> Maciej, >> >> did this sound reasonable to you? >> >> >> Still doesn't make sense to me. Even if we don't implement CSS >> 'alpha-compositing' and 'blend-mode' today, I assume we will want to >> implement them eventually. At that point we will want them consistent with >> Canvas. If the only reason to combine compositing operator and blend modes >> is short-term ease of implementation on Mac, then that doesn't seem like a >> great reason to make the Web platform permanently inconsistent. >> >> Would you object if Canvas combines blending and compositing but not CSS? >> >> >> Yes. I think they should be consistent and the relevant standards group >> (FX Task Force?) should decide. It's not even very important to me which is >> chosen. It just seems arbitrary that they would make different choices on >> this, especially when it is all defined in the same spec. >> >> > Thanks Maciej! > I will bring this up on the FX mailing list. > Depending on the outcome, I will amend the compositing spec. > > > Thanks, that would be much appreciated. > > Hi Maciej, I send the question to the fx list. Tab Atkins brought up that we could extend the 'globalCompositeOperator' so it also takes a comma separate list of a blend and a compositing operation. Calling: mycontext.globalCompositeOperator = 'multiply'; would be identical to: mycontext.globalCompositeOperator = 'multiply, source-over'; This would make Canvas support blending and compositing and can be implemented with no compatibility issues later. Does this ease your concern about the difference between Canvas and CSS? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Tue, Nov 13, 2012 at 11:19 PM, Maciej Stachowiak wrote: > > On Nov 13, 2012, at 4:43 PM, Rik Cabanier wrote: > > Maciej, > > did this sound reasonable to you? > > > Still doesn't make sense to me. Even if we don't implement CSS > 'alpha-compositing' and 'blend-mode' today, I assume we will want to > implement them eventually. At that point we will want them consistent with > Canvas. If the only reason to combine compositing operator and blend modes > is short-term ease of implementation on Mac, then that doesn't seem like a > great reason to make the Web platform permanently inconsistent. > > Would you object if Canvas combines blending and compositing but not CSS? > > > Yes. I think they should be consistent and the relevant standards group > (FX Task Force?) should decide. It's not even very important to me which is > chosen. It just seems arbitrary that they would make different choices on > this, especially when it is all defined in the same spec. > > Thanks Maciej! I will bring this up on the FX mailing list. Depending on the outcome, I will amend the compositing spec. > > On Mon, Nov 12, 2012 at 3:46 PM, Rik Cabanier wrote: > >> >> >> On Mon, Nov 12, 2012 at 12:14 PM, Maciej Stachowiak wrote: >> >>> >>> On Nov 11, 2012, at 9:06 PM, Rik Cabanier wrote: >>> >>> >>> >>> On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak wrote: >>> >>>> >>>> On Nov 11, 2012, at 6:59 PM, Rik Cabanier wrote: >>>> >>>> >>>> >>>> >>>>> >>>>> Wouldn't it be better to add a new property to canvas for blending? At >>>>> the beginning, implementations are just require to use different blend >>>>> modes in combination with 'source-over'. >>>> >>>> >>>> That could work too. >>>> There was a mailing list conversation about this a couple of months >>>> ago, and people were evenly split on the subject. >>>> >>>> The vast majority of cases will use 'source-over' in combination with >>>> blending so maybe it's best to keep it simple... >>>> >>>> >>>> It doesn't make sense to me for blend mode and composite operator to be >>>> separate in CSS, but combined in Canvas. Either there are valid use cases >>>> for specifying them separately or there are not. I cannot imagine how this >>>> could differ between Canvas and CSS. >>>> >>>> There are cases where it makes sense to have them as separate >>> properties. >>> To be honest, the main reason that the Canvas proposal combines them, is >>> because it is not possible to implement this efficiently using Core >>> Graphics. >>> >>> If we break it up in 2 operations, we have to document the correct >>> behavior (= blending does not force source-over for blending) because the >>> spec can't be changed later. >>> This means that Safari and Firefox for Mac can only implement part of >>> the spec... >>> >>> I prefer to have a consistent implementation that can be extended later >>> as opposed to a 'correct' API that is inconsistently implemented. >>> >>> >>> Doesn't this same argument apply to CSS blend modes? (And therefore the >>> 'blend-mode' and 'alpha-compositing' properties should be combined into a >>> single property)? >>> >>> >> Yes, except I'm not proposing that we implement the 'alpha-compositing' >> property yet. >> I hope that MacOS (or Safari) can evolve in the future so it can be >> implemented more easily. >> >> Compositing in CSS is actually a much harder problem than in Canvas >> because it requires the UA to keep track of the 'shape'. >> >> > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
Maciej, did this sound reasonable to you? Would you object if Canvas combines blending and compositing but not CSS? Rik On Mon, Nov 12, 2012 at 3:46 PM, Rik Cabanier wrote: > > > On Mon, Nov 12, 2012 at 12:14 PM, Maciej Stachowiak wrote: > >> >> On Nov 11, 2012, at 9:06 PM, Rik Cabanier wrote: >> >> >> >> On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak wrote: >> >>> >>> On Nov 11, 2012, at 6:59 PM, Rik Cabanier wrote: >>> >>> >>> >>> >>>> >>>> Wouldn't it be better to add a new property to canvas for blending? At >>>> the beginning, implementations are just require to use different blend >>>> modes in combination with 'source-over'. >>> >>> >>> That could work too. >>> There was a mailing list conversation about this a couple of months ago, >>> and people were evenly split on the subject. >>> >>> The vast majority of cases will use 'source-over' in combination with >>> blending so maybe it's best to keep it simple... >>> >>> >>> It doesn't make sense to me for blend mode and composite operator to be >>> separate in CSS, but combined in Canvas. Either there are valid use cases >>> for specifying them separately or there are not. I cannot imagine how this >>> could differ between Canvas and CSS. >>> >>> There are cases where it makes sense to have them as separate properties. >> To be honest, the main reason that the Canvas proposal combines them, is >> because it is not possible to implement this efficiently using Core >> Graphics. >> >> If we break it up in 2 operations, we have to document the correct >> behavior (= blending does not force source-over for blending) because the >> spec can't be changed later. >> This means that Safari and Firefox for Mac can only implement part of the >> spec... >> >> I prefer to have a consistent implementation that can be extended later >> as opposed to a 'correct' API that is inconsistently implemented. >> >> >> Doesn't this same argument apply to CSS blend modes? (And therefore the >> 'blend-mode' and 'alpha-compositing' properties should be combined into a >> single property)? >> >> > Yes, except I'm not proposing that we implement the 'alpha-compositing' > property yet. > I hope that MacOS (or Safari) can evolve in the future so it can be > implemented more easily. > > Compositing in CSS is actually a much harder problem than in Canvas > because it requires the UA to keep track of the 'shape'. > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Mon, Nov 12, 2012 at 12:14 PM, Maciej Stachowiak wrote: > > On Nov 11, 2012, at 9:06 PM, Rik Cabanier wrote: > > > > On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak wrote: > >> >> On Nov 11, 2012, at 6:59 PM, Rik Cabanier wrote: >> >> >> >> >>> >>> Wouldn't it be better to add a new property to canvas for blending? At >>> the beginning, implementations are just require to use different blend >>> modes in combination with 'source-over'. >> >> >> That could work too. >> There was a mailing list conversation about this a couple of months ago, >> and people were evenly split on the subject. >> >> The vast majority of cases will use 'source-over' in combination with >> blending so maybe it's best to keep it simple... >> >> >> It doesn't make sense to me for blend mode and composite operator to be >> separate in CSS, but combined in Canvas. Either there are valid use cases >> for specifying them separately or there are not. I cannot imagine how this >> could differ between Canvas and CSS. >> >> There are cases where it makes sense to have them as separate properties. > To be honest, the main reason that the Canvas proposal combines them, is > because it is not possible to implement this efficiently using Core > Graphics. > > If we break it up in 2 operations, we have to document the correct > behavior (= blending does not force source-over for blending) because the > spec can't be changed later. > This means that Safari and Firefox for Mac can only implement part of the > spec... > > I prefer to have a consistent implementation that can be extended later as > opposed to a 'correct' API that is inconsistently implemented. > > > Doesn't this same argument apply to CSS blend modes? (And therefore the > 'blend-mode' and 'alpha-compositing' properties should be combined into a > single property)? > > Yes, except I'm not proposing that we implement the 'alpha-compositing' property yet. I hope that MacOS (or Safari) can evolve in the future so it can be implemented more easily. Compositing in CSS is actually a much harder problem than in Canvas because it requires the UA to keep track of the 'shape'. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Mon, Nov 12, 2012 at 12:07 PM, Ilyes Gouta wrote: > Hi, > > On Nov 12, 2012 4:39 PM, "Dirk Schulze" wrote: > > > > > > On Nov 11, 2012, at 10:09 PM, "Rik Cabanier" wrote: > > > >> > >> > >> On Sun, Nov 11, 2012 at 9:52 PM, Dirk Schulze wrote: > >>> > >>> > >>> > >>> On Sunday, November 11, 2012, Rik Cabanier wrote: > >>>> > >>>> > >>>> > >>>> On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak > wrote: > >>>>> > >>>>> > >>>>> On Nov 11, 2012, at 6:59 PM, Rik Cabanier > wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Wouldn't it be better to add a new property to canvas for > blending? At the beginning, implementations are just require to use > different blend modes in combination with 'source-over'. > >>>>>> > >>>>>> > >>>>>> That could work too. > >>>>>> There was a mailing list conversation about this a couple of months > ago, and people were evenly split on the subject. > >>>>>> > >>>>>> The vast majority of cases will use 'source-over' in combination > with blending so maybe it's best to keep it simple... > >>>>> > >>>>> > >>>>> It doesn't make sense to me for blend mode and composite operator to > be separate in CSS, but combined in Canvas. Either there are valid use > cases for specifying them separately or there are not. I cannot imagine how > this could differ between Canvas and CSS. > >>> > >>> > >>> To be fair, the 'globalCompositOperator' property mixed the > compositing modes with some blend modes already. Which is the fault of the > WebKit implementation. IIRC they have been removed from the Canvas part of > the HTML spec for some time, but were added later again. Now we have > multiple independent implementations that support all currently specified > operators. > >> > >> > >> Is this the 'darker' compositing mode or are there others? > > > > > > Lighter and darker, yes. > > Is additive blending also specified/supported? > They are not. I proposed adding all the photoshop blend modes to the spec but got pushback. They are also not part of Core Graphics so it would be hard to implement them. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Sun, Nov 11, 2012 at 9:52 PM, Dirk Schulze wrote: > > > On Sunday, November 11, 2012, Rik Cabanier wrote: > >> >> >> On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak wrote: >> >>> >>> On Nov 11, 2012, at 6:59 PM, Rik Cabanier wrote: >>> >>> >>> >>> >>>> >>>> Wouldn't it be better to add a new property to canvas for blending? At >>>> the beginning, implementations are just require to use different blend >>>> modes in combination with 'source-over'. >>> >>> >>> That could work too. >>> There was a mailing list conversation about this a couple of months ago, >>> and people were evenly split on the subject. >>> >>> The vast majority of cases will use 'source-over' in combination with >>> blending so maybe it's best to keep it simple... >>> >>> >>> It doesn't make sense to me for blend mode and composite operator to be >>> separate in CSS, but combined in Canvas. Either there are valid use cases >>> for specifying them separately or there are not. I cannot imagine how this >>> could differ between Canvas and CSS. >>> >> > To be fair, the 'globalCompositOperator' property mixed the compositing > modes with some blend modes already. Which is the fault of the WebKit > implementation. IIRC they have been removed from the Canvas part of the > HTML spec for some time, but were added later again. Now we have multiple > independent implementations that support all currently specified operators. > Is this the 'darker' compositing mode or are there others? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak wrote: > > On Nov 11, 2012, at 6:59 PM, Rik Cabanier wrote: > > > > >> >> Wouldn't it be better to add a new property to canvas for blending? At >> the beginning, implementations are just require to use different blend >> modes in combination with 'source-over'. > > > That could work too. > There was a mailing list conversation about this a couple of months ago, > and people were evenly split on the subject. > > The vast majority of cases will use 'source-over' in combination with > blending so maybe it's best to keep it simple... > > > It doesn't make sense to me for blend mode and composite operator to be > separate in CSS, but combined in Canvas. Either there are valid use cases > for specifying them separately or there are not. I cannot imagine how this > could differ between Canvas and CSS. > > There are cases where it makes sense to have them as separate properties. To be honest, the main reason that the Canvas proposal combines them, is because it is not possible to implement this efficiently using Core Graphics. If we break it up in 2 operations, we have to document the correct behavior (= blending does not force source-over for blending) because the spec can't be changed later. This means that Safari and Firefox for Mac can only implement part of the spec... I prefer to have a consistent implementation that can be extended later as opposed to a 'correct' API that is inconsistently implemented. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding blending mode to WebKit canvas
On Sun, Nov 11, 2012 at 5:25 PM, Dirk Schulze wrote: > > On Nov 9, 2012, at 4:39 PM, Rik Cabanier wrote: > > > Hi, > > > > I'd like to add support for blending modes to Canvas. > > The spec for this feature can be found here: > https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending > > > > The implementation will be tracked by a meta bug: > https://bugs.webkit.org/show_bug.cgi?id=100069 > > I also attached a large patch that shows how this feature can be > implemented. > > Looking at your patches on bug 100069 and bug 101804, I actually have some > questions. If I understand your API changes correctly, the > 'globalCompositeOperation' property gets more keywords. The new keywords > will be the same as for the 'blend-mode' property of the CSS Compositing > spec. Does it mean that blend mode always will use the compositing operator > 'source-over'? > Correct. >From the spec [1]: Blending is not separated from compositing in canvas 2d. If a blend operation is selected its results must always be composited with the ‘ source-over’<https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#porterduffcompositingoperators_srcover> compositing mode. > > The example implementation of > GraphicsContext::setPlatformCompositeOperation on CG indicates that it > would be possible to combine blend modes with different compositing > operators in CG already. Unfortunately, CG can't do this (yet). The code is written to minimize change and to make this split easy to implement in the future. > If you set both with the same property 'globalCompositeOperation', it > won't be possible to mix them in the future. If more implementations are > capable to support mixing alpha compositing and blending, the property can > not be changed anymore. > Well, it can still be changed. If in the future, people feel the need to specify blending and compositing separately, we can define a new property (globalBlendOperation?) that specifies the blending operation before globalCompositeOperation. If a user specifies a blending operation in both globalBlendOperation and globalCompositeOperation, we can define that globalCompositeOperation reverts to source-over. > > Wouldn't it be better to add a new property to canvas for blending? At the > beginning, implementations are just require to use different blend modes in > combination with 'source-over'. That could work too. There was a mailing list conversation about this a couple of months ago, and people were evenly split on the subject. The vast majority of cases will use 'source-over' in combination with blending so maybe it's best to keep it simple... > Btw. why is this addition in CSS Compositing and not in the Canvas spec? > > I got feedback that it was best to specify this in the compositing spec since it explains in detail how the formulas work and has pretty pictures. The canvas spec can be changed to refer to the blending spec. Rik 1: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding blending mode to WebKit canvas
Hi, I'd like to add support for blending modes to Canvas. The spec for this feature can be found here: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending The implementation will be tracked by a meta bug: https://bugs.webkit.org/show_bug.cgi?id=100069 I also attached a large patch that shows how this feature can be implemented. Please let me know of any concerns. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
On Fri, Oct 26, 2012 at 9:06 AM, Peter Kasting wrote: > On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier wrote: > >> It is valid for a const method to return you a new object ie a const >> factory object. >> In that case, const-ness would not be desired. >> > > Not really. The point of this thread is that such functions may not > modify an object's state themselves, but they vend access that can be used > by the caller to modify it. > > Consider for example: > > Child* Parent::getNewChild() const; > > Assuming the Parent doesn't have a list of its children (questionable), we > can implement this without mutable pointers. But then a caller can do: > > Child* child = parent->getNewChild(); > child->parent->mutate(); > this would only be possible if that parent object is casting away a 'const' somewhere or accessing a global non-const object. Maybe there should be a rule that 'mutable' or 'const_cast' should not be allowed. > > If you generalize this you find there are very, very few cases where a > const object can vend a non-const pointer that cannot possibly be used to > change the state of the world the const object sees. Which is why the rule > of thumb suggested in this thread is safer and easier than trying to reason > about individual cases. > > PK > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
It is valid for a const method to return you a new object ie a const factory object. In that case, const-ness would not be desired. Rik On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling wrote: > Yo WebKittens! > > After some mild morning discussion in #webkit, I'm wondering if we should > amend our style guide to disallow returning mutable pointers (Foo*) from > const methods, like so: > > - Foo* foo() const; > > While this is useful when you want to be able to take a strong reference > to the returned object, i.e by assigning it to a RefPtr, it's > counter-intuitive as it encourages "read-only" methods to hand out > "read/write" references to internal data. > > I've been using const-ness to prevent certain classes of bugs at compile > time for the immutable/mutable implementations of WebCore's > ElementAttributeData and StylePropertySet. It's especially important that > the immutable versions of these objects don't have their internal data > modified by unwitting external clients, since they may be shared between > multiple owners. While using assertions helps us catch incorrect use of > these objects, it's obviously optimal to catch the bugs already at compile > time. > > I just now discovered that you can grab at a mutable CSSValue* pointer in > an immutable "const StylePropertySet*" by going through > propertyAt(index).value(), since we have "CSSValue* CSSProperty::value() > const". This is bad, because it means that we have a bunch of call sites > operating on mutable pointers into what's supposed to be an immutable > object! > > While I haven't identified any real bugs caused by this (yet), it would be > easy to introduce one by mistake. > > So, I propose that we allow only these two signature formats for raw > pointers: > > - const Foo* foo() const; > - Foo* foo(); > > Moreover, for methods that return references to objects where call sites > are expected to take a strong reference, we should really be using > PassRefPtr as the return type. > > Thoughts? Objections? Am I missing something? > > -Kling > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New Feature: Canvas Path object
On Mon, Sep 24, 2012 at 10:27 AM, Darin Adler wrote: > On Sep 22, 2012, at 9:21 PM, Elliott Sprehn wrote: > > > On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze > wrote: > > > >> I would like to ask if there are objections to implement the canvas > Path object. > > > > Do we have metrics on how often people already have things named Path? > All other canvas objects have a prefix like CanvasGradient and > CanvasPattern, this thing seems inconsistent and more likely to break > existing pages. > > Dirk, given the fact that you quite logically referred to this as “the > canvas Path object” when mentioning it to us, and the fact that both > CanvasGradient and CanvasPattern objects exist, CanvasPath sure does seem > like a nice name for this. Someone should make that suggestion on the > WebApps mailing list! > > A difference though is that the path object doesn't have to be associated with a canvas. It is/will be useful with other features such as SVG as well. I feel uneasy with the generic name too; maybe a DOM/HTML/JS prefix is better. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding CSS blending to WebKit
I changed all the project files that were modified for the CSS_SHADERS define but my patch was denied because it didn't modify the makefiles for every single platform. Do I really have to modify all of them? Rik On Fri, Jul 27, 2012 at 6:06 PM, Dean Jackson wrote: > > On 21/07/2012, at 8:50 AM, Rik Cabanier wrote: > > I'm planning on adding CSS blending to WebKit: > https://bugs.webkit.org/show_bug.cgi?id=91908 > We already have a working prototype and I will bring it over as a couple > of patches. > > We did a couple of write-ups on this feature: > > https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html > http://blogs.adobe.com/webplatform/2012/04/04/bringing-blending-to-the-web/ > http://blogs.adobe.com/webplatform/2012/07/17/new-blending-features-in-css/ > http://html.adobe.com/webstandards/csscompositing/ > > > > This is my first time contributing so let me know if there is another > process I should follow. > > > Rik didn't mention this will be protected by a feature flag: > ENABLE_CSS_COMPOSITING seems to be the suggestion. > > Dean > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding CSS blending to WebKit
All, I'm planning on adding CSS blending to WebKit: https://bugs.webkit.org/show_bug.cgi?id=91908 We already have a working prototype and I will bring it over as a couple of patches. We did a couple of write-ups on this feature: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html http://blogs.adobe.com/webplatform/2012/04/04/bringing-blending-to-the-web/ http://blogs.adobe.com/webplatform/2012/07/17/new-blending-features-in-css/ http://html.adobe.com/webstandards/csscompositing/ This is my first time contributing so let me know if there is another process I should follow. Rik Cabanier Adobe Systems ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)
This might no longer be true, but isn't it the case that shaders are designed to take the same amount of time to execute, no matter what input they get? ie if you have an if/else block, the time of the shader would be whatever block takes the longest. This was done so you can schedule many of them at the same time without having to worry about synchronizing them. Rik On Mon, Dec 5, 2011 at 3:34 PM, Chris Marrin wrote: > > On Dec 5, 2011, at 11:32 AM, Adam Barth wrote: > > > On Mon, Dec 5, 2011 at 10:53 AM, Chris Marrin wrote: > >> To be clear, it's not the difference between white and black pixels, > it's > >> the difference between pixels with transparency and those without. > > > > Can you explain why the attack is limited to distinguishing between > > black and transparent pixels? My understanding is that these attacks > > are capable of distinguishing arbitrary pixel values. > > This is my misunderstanding. I was referring to the attacks using WebGL, > which measure the difference between rendering alpha and non-alpha pixels. > But I think there is another, more dangerous attack vector specific to CSS > shaders. Shaders have the source image (the image of that part of the page) > available. So it is an easy thing to make a certain color pixel take a lot > longer to render (your "1000x slower" case). So you can easily and quickly > detect, for instance, the color of a link. > > So I take back my statement that CSS Shaders are less dangerous than > WebGL. They are more!!! As I've said many times (with many more > expletives), I hate the Internet. > > I think the solution is clear. We should create a whole new internet where > we only let in people we trust. :-) > > - > ~Chris > cmar...@apple.com > > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
Dean, could you implement the filters on top of shaders if the target has WEBGL acceleration? Doing animated filters in software will be slow unless you spend a significant amount of time on coding SSE or NEON instructions. Rik On Mon, Oct 24, 2011 at 9:02 PM, Dean Jackson wrote: > > On 22/09/2011, at 11:30 AM, Dean Jackson wrote: > > > Dirk (known in these parts as krit) reminded me that I had not emailed > webkit-dev about the plans to start an implementation of W3C's new Filter > Effects specification. > > > > https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html > > > > The quick summary is that this exposes the 'filter' property from SVG to > everything in CSS, and adds some shorthands for common effects so people > don't have to write XML in order to do something like a blur or sepia > effect. The spec has received a fair amount of input from the CSS and SVG > working groups, and particularly from Apple, Google, Mozilla, Opera and > Adobe. > > A followup: we're going to start work on the CSS Shaders proposal [1] > soon. Adobe have published their implementation which was specific to > Chromium, and we'll be working with them to split it into small patches > that can land in the coming weeks. A good introduction to the technology is > [2]. > > This will be done behind the ENABLE_CSS_FILTERS macro, but also with the > guards for ENABLE_WEBGL since the implementation (and security) > requirements are so similar. > > Dean > > [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html > [2] www.adobe.com/devnet/html5/articles/css-shaders.html > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
