Re: Disabling non-Skia builds
I'm 100% in support of this. One thing I'd like to know though is how we're going to deal with upstreaming patches to Skia on behalf of third parties? In my experience, it's rarely been a case of simply submitting a patch and having it accepted; there's normally a decent amount of engineering effort required to make it acceptable to upstream. I think it would be nice to have some sort of plan figured out (even if it's "people submitting patches to us should probably consult upstream first") before we flip the kill switch here. On 12/13/2016 4:39 PM, Milan Sreckovic wrote: In https://bugzilla.mozilla.org/show_bug.cgi?id=1323303, we are going to disable the build configurations that let us leave Skia out. This will let us simplify the code, and make things cleaner, now that it is the only supported backend. We will take patches to Gecko (or forward them if in Skia itself) that fix problems related to Tier 3 platforms, although we don't anticipate anything coming in for SkiaGL. -- - Milan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deprecate: Building mozilla-central without Skia enabled
I'm looking to remove the option to build mozilla-central without Skia. Currently we default to Skia being disabled, and enable it using --enable-skia. This is problematic because all of our officially supported build configurations enable Skia, and as such the Skia-is-disabled build has been buggy for quite some time. This has manifested most recently in bug 1296524. In the past year, Skia has moved from being an optional part of our graphics code to being a core, indispensable module. We are actively pursuing making it the default backend in almost all canvas and content configurations; it is already the default software canvas option on all platforms and will soon be for all software-backed content as well. To this end, I'd like to remove support for building mozilla-central without Skia as I think it should now be considered an integral part of our code. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a OSS project!
On 05/09/2016 04:59 PM, Tobias B. Besemer wrote: But I'm pretty sure that it wouldn't take anymore long till Mozilla is on the ground... It seems a bit odd that you're using the "you will lose marketshare" argument in favour of your demands, but in the content process bug your demands basically boiled down to "you should rename the processes to X, Y and who cares if it breaks the browsing experience for people because the stuff it breaks doesn't affect me personally" (comments 143 and 145). I'm pretty sure we'll lose users if we break the browsing experience for them. I engaged in a civil discussion explaining why we couldn't go down the route you suggested (I tried to land that originally, and it was backed out from Nightly after it became apparent that it was a browser-breaking change) and you responded with ranting and accusations of foul play due to not being an employee. I will reiterate what Andrew said - you are not being dismissed because you are not an employee. In fact, we engaged in discussions with you regarding your concerns and explaining why we were unable to do them. It was only after you started ranting because the discussions didn't go your way that we started to dismiss you because there was nothing constructive to discuss. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is there an e10s plan for multiple content processes?
On 05/05/15 16:40, Mike Hommey wrote: Last time I tried e10s, which was a while ago, tab switching did feel weird with e10s *because* of that lack of the browser lock-up, because now, the tab strip shows you've switched tabs, but the content is still from before switching, until the spinner shows up or the new content appears. I changed that behaviour a while ago. Now we wait for the content to be ready, or for the spinner to show (if we've waited 300ms and content still isn't ready) before we update the tab strip. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
On 2015-04-07 8:48 AM, Benjamin Smedberg wrote: Is the duration of this delay measured in telemetry anywhere, and do we have criteria for how much delay is acceptable in this case? If e10s were off, do we expect that this same delay would occur but would just show up as a jank switching tabs? Or is this a perf problem unique to e10s? We've discussed adding telemetry probes to measure page painting time so we can properly gauge what the impact is of e10s vs non-e10s. See https://bugzilla.mozilla.org/show_bug.cgi?id=1135719 for the bug tracking page render time issues. In terms of "acceptable" delay, the current working value is 300ms; as in, we fire off a request, wait up to 300ms, switch the tab if it's ready before 300ms, or show the spinner after 300ms and switch the tab if content isn't ready. We've made a lot of changes to this code in the last two weeks so things should be noticeably better than it was before then. As Bill said, non-e10s would just jank if we waited a noticeable amount of time for a page to render, but I think (based on gut feeling rather than any hard data) that e10s seems to be a little slower to paint than non-e10s. I haven't been able to confirm that or reproduce it reliably though. The spinner is also temporary right now, and we're waiting on UX to provide us with an approved spinner in https://bugzilla.mozilla.org/show_bug.cgi?id=1049551. I don't know if they're ok with the one that's currently there but I wonder if the bug being marked as resolved is making them deprioritise it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
On 03/27/2013 07:37 PM, Robert O'Callahan wrote: > I predict that eventually we'll want to switch mozilla-central to git. (I'm > not in favour of it, but hg is not the DVCS of the future.) So, git users > not liking git's subrepositories gives me pause and I think it's imperative > to consider the situation of git users now and after a hypothetical > mozilla-central switch to git. I've investigated submodules before to try to solve this exact problem and came away pretty unimpressed. This was nearly 3 or 4 years ago, but I doubt things have changed much. A quick search suggests that other people are also similarly unimpressed with submodules, such as the post at http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ I suspect the answer here would be to choose a solution that is easily convertible to a repo-style setup. We already have experience in-house with repo due to Android and B2G and it seems to mostly do what we would be aiming for with this project. On the main note (which I already brought up on IRC): I would be very interested in seeing whether this experiment succeeds or not, as I'd like to get to the stage where the entire Skia source tree inside mozilla-central is just a checkout of upstream Skia, whether that's via submodules or repo or whatever. George ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OpenVG Azure backend
On 02/23/2013 04:00 PM, Andreas Gal wrote: > OpenVG is a Khronos standard API for GPU accelerated 2D rendering. Its very > similar to OpenGL in design. In fact, its an alternative API to OpenGL ES on > top of EGL. It looks like that OpenVG is supported on most Android devices > and is used there by Flash (or well used to be used). B2G devices have OpenVG > support as well. There are also a number of open source implementations of > OpenVG that use OpenGL to accelerate 2D operations that might be interesting > for the desktop. OpenVG is pretty similar to Cairo and Skia when it comes to > the actual operations offered. The biggest drawback of OpenVG is that it > doesn't mix well with OpenGL. Its possible to render with OpenVG to a texture > and then composite that with OpenGL, but its not possible to do mixed > rendering with VG and GL to the same surface. That having said, I still think > we should consider adding an OpenVG backend. It would potentially > significantly speed up rendering on mobile hardware. OpenVG is quite a bit > more seasoned t > han Skia/SkiaGL, and explicitly targets mobile, whereas SkiaGL seems to be > mostly optimized for the desktop (at least so far). A particular advantage of > OpenVG is that it can take advantage of dedicated 2D acceleration hardware > (Mali and Adreno both have special 2D hardware OpenVG uses). SkiaGL on the > other hand is limited to using GLES to accelerate 2D drawing operations. What > do people think. Should we add a OpenVG backed? > My (very limited) knowledge about OpenVG is that people in the industry at the vendor level tend to not care about it. I think the reason for this is basically that there aren't any significant users of OpenVG (WebKit used to have a VG backend but it only had one user and has now been disowned). As a result of this indifference from the vendors, my understanding is that there aren't any actual hardware accelerated VG implementations. I think Qualcomm used to have one, but if I remember correctly they didn't really want to keep maintaining it. I think we're about 3 or 4 years too late to the OpenVG party and at this point we'd be trying to resurrect it, rather than use it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
