Re: A list of easy-ish gfxContext-to-DrawTarget conversions
On Tue, Jan 12, 2016 at 4:30 PM, Jeff Gilbert wrote: > For a similar situation, we used an etherpad to allow painless > acquisition of pending todos. Good idea. I created https://public.etherpad-mozilla.org/p/EasyDrawTarget for this purpose. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Spec workshop: Grid Layout
I've started doing a series of workshops inviting web authors to get together and do an in-depth study of some of the CSS layout specs together, the goal being to find problems and improve readability. If this seems interesting to you, there's more information here: http://fantasai.inkedblade.net/style/events/flex-workshop http://fantasai.inkedblade.net/style/events/grid-workshop I'm planning to organize one for Grid Layout in the SF Bay Area this month and NYC next month; but I also think people here who want to could probably do a good job running one themselves wherever is convenient. :) The formula is summarized by Simon Sapin here: https://twitter.com/SimonSapin/status/658219116797427712 and more detailed instructions are in the flex workshop page. If you do, please send any feedback back to the spec editors, e.g. to www-st...@w3.org for CSS. Happy coding~ ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A list of easy-ish gfxContext-to-DrawTarget conversions
For a similar situation, we used an etherpad to allow painless
acquisition of pending todos. Just move the instances you want
'assigned' to you into a section in the etherpad. It's not
perfect, but it's an alternative to responding to the email, and makes
it easy to see the state of things.
On Tue, Jan 12, 2016 at 2:54 PM, Nicholas Nethercote
wrote:
> Greetings,
>
> Over the past few weeks I have spent some time doing gfxContext-to-DrawTarget
> conversions. (Also nsRendering-to-DrawTarget conversions, which are basically
> the same because nsRenderingContext is a wafer-thin wrapper around
> gfxContext.)
>
> The number of occurrences of gfxContext and nsRenderingContext is now about
> 20% lower than when I started (it went from 1813 to 1428), but I now need to
> work on other things. Below is a list of cases that I didn't get to, but which
> look like they might be easy-ish for people with some Thebes/Moz2D
> experience.
>
> If you do work on any of these, it might be worth replying to this message to
> indicate this, to reduce the chance of two people duplicating work.
>
> - gfxAlphaBoxBlur::Init(): the return value.
>
> - gfxAlphaBoxBlur::BlurInsetBox() + FillDestinationPath(): the parameters.
>
> - gfxAlphaBoxBlur::Paint() + DrawBlur(): the parameters.
>
> - nsNativeThemeWin::DrawWidgetBackground: the parameter, in tandem with
> changing gfxWindowsNativeDrawing::mContext and
> gfxWindowsNativeDrawing::BeginNativeDrawing().
>
> - nsCSSRendering::PaintGradient(): the parameter.
>
> - DocumentRenderParent::mCanvasContext.
>
> - ClipToContain() in BasicLayerManager.cpp: the parameter.
>
> - PaintLayerContext::mTarget.
>
> - InstallLayerClipPreserves3D() in BasicLayerManager.cpp: the parameter.
>
> - PaintWithMask() in BasicLayersImpl.cpp: the parameter.
>
> - gfxTextContextPaint::InitStrokeGeometry(): the parameter.
>
> - imgFrame::SurfaceForDrawing(): the parameter.
>
> - nsLayoutUtils::GetSnappedBaseline{X,Y}(): the parameter.
>
> - ComputeSnappedImageDrawingParameters(): the parameter.
>
> - The Android instance of nsPluginInstanceOwner::Paint(): the parameter.
>
> - nsSVGUtils::SetClipRect(): the parameter.
>
> - nsSVGUtils::Make{Fill,Stroke}PatternFor(): the parameter.
>
> - BufferAlphaColor::mContext.
>
> - DrawBackgroundColor() in nsCSSRendering.cpp: the parameter.
>
> - SetupBackgroundClip() in nsCSSRendering.cpp: the parameter.
>
> - MustCreateSurface() in ClippedImage.cpp.
>
> - nsCSSRendering::PaintGradient(): the nsRenderingContext parameter.
>
> - DumpFrames() in nsPrintEngine.cpp: this is commented-out code and it won't
> compile because the nsRenderingContext is used in a bogus way (the call to
> IsVisibleForPainting() has too many arguments). Perhaps all the
> EXTENDED_DEBUG_PRINTING code can be removed? It looks ancient.
>
> - Three CreateReferenceRenderingContext() call sites only require a
> DrawTarget (nsTextBoxFrame::DrawText(), CreateReferenceDrawTarget(),
> LazyReferenceRenderingDrawTargetGetterFromFrame::GetRefDrawTarget()), so
> creating a gfxContext is overkill.
>
> Finally, if I could choose a single function to magically Moz2Dify, it would
> be
> AppUnitWidthOfStringBidi(). Changing its nsRenderingContext parameter to a
> DrawTarget would allow huge swathes of functions to be changed similarly, as
> well as nsBoxLayoutState::mRenderingContext and nsCSSOffsetState::rendContext.
> But it's a hard case; the embedded gfxContext end up being passed through
> nsFontMetrics::DrawString() to gfxTextRun::Draw() where it is put into a
> TextRunDrawParams and gets used in lots of complicated ways.
>
> Nick
> ___
> 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
A list of easy-ish gfxContext-to-DrawTarget conversions
Greetings,
Over the past few weeks I have spent some time doing gfxContext-to-DrawTarget
conversions. (Also nsRendering-to-DrawTarget conversions, which are basically
the same because nsRenderingContext is a wafer-thin wrapper around gfxContext.)
The number of occurrences of gfxContext and nsRenderingContext is now about
20% lower than when I started (it went from 1813 to 1428), but I now need to
work on other things. Below is a list of cases that I didn't get to, but which
look like they might be easy-ish for people with some Thebes/Moz2D
experience.
If you do work on any of these, it might be worth replying to this message to
indicate this, to reduce the chance of two people duplicating work.
- gfxAlphaBoxBlur::Init(): the return value.
- gfxAlphaBoxBlur::BlurInsetBox() + FillDestinationPath(): the parameters.
- gfxAlphaBoxBlur::Paint() + DrawBlur(): the parameters.
- nsNativeThemeWin::DrawWidgetBackground: the parameter, in tandem with
changing gfxWindowsNativeDrawing::mContext and
gfxWindowsNativeDrawing::BeginNativeDrawing().
- nsCSSRendering::PaintGradient(): the parameter.
- DocumentRenderParent::mCanvasContext.
- ClipToContain() in BasicLayerManager.cpp: the parameter.
- PaintLayerContext::mTarget.
- InstallLayerClipPreserves3D() in BasicLayerManager.cpp: the parameter.
- PaintWithMask() in BasicLayersImpl.cpp: the parameter.
- gfxTextContextPaint::InitStrokeGeometry(): the parameter.
- imgFrame::SurfaceForDrawing(): the parameter.
- nsLayoutUtils::GetSnappedBaseline{X,Y}(): the parameter.
- ComputeSnappedImageDrawingParameters(): the parameter.
- The Android instance of nsPluginInstanceOwner::Paint(): the parameter.
- nsSVGUtils::SetClipRect(): the parameter.
- nsSVGUtils::Make{Fill,Stroke}PatternFor(): the parameter.
- BufferAlphaColor::mContext.
- DrawBackgroundColor() in nsCSSRendering.cpp: the parameter.
- SetupBackgroundClip() in nsCSSRendering.cpp: the parameter.
- MustCreateSurface() in ClippedImage.cpp.
- nsCSSRendering::PaintGradient(): the nsRenderingContext parameter.
- DumpFrames() in nsPrintEngine.cpp: this is commented-out code and it won't
compile because the nsRenderingContext is used in a bogus way (the call to
IsVisibleForPainting() has too many arguments). Perhaps all the
EXTENDED_DEBUG_PRINTING code can be removed? It looks ancient.
- Three CreateReferenceRenderingContext() call sites only require a
DrawTarget (nsTextBoxFrame::DrawText(), CreateReferenceDrawTarget(),
LazyReferenceRenderingDrawTargetGetterFromFrame::GetRefDrawTarget()), so
creating a gfxContext is overkill.
Finally, if I could choose a single function to magically Moz2Dify, it would be
AppUnitWidthOfStringBidi(). Changing its nsRenderingContext parameter to a
DrawTarget would allow huge swathes of functions to be changed similarly, as
well as nsBoxLayoutState::mRenderingContext and nsCSSOffsetState::rendContext.
But it's a hard case; the embedded gfxContext end up being passed through
nsFontMetrics::DrawString() to gfxTextRun::Draw() where it is put into a
TextRunDrawParams and gets used in lots of complicated ways.
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Core Guidelines
On 2016-01-06 7:15 AM, Henri Sivonen wrote: On Thu, Oct 1, 2015 at 9:58 PM, Jonathan Watt wrote: For those who are interested in this, there's a bug to consider integrating the Guidelines Support Library (GSL) into the tree: https://bugzilla.mozilla.org/show_bug.cgi?id=1208262 This bug appears to have stalled. What should my expectations be regarding getting an equivalent of (at least single-dimensional) GSL span (formerly array_view; conceptually Rust's slice) into MFBT? I'll investigate integrating gsl-lite into m-c. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: any concerns with dropping the talos test v8 and using AWFY Octane instead?
On 2016-01-11 4:12 PM, Eric Rahm wrote: On Monday, January 11, 2016 at 8:42:11 AM UTC-8, William Lachance wrote: It seems like another alternative might be to run Octane in Talos, instead of v8_7. It seems like Talos has two advantages over AWFY (correct me if I'm wrong): 1. Easy for developers to schedule jobs via try (maybe less of a concern with a benchmark like this, where I suspect results are more reproducible locally?) I believe there was talk of adding try support for AWFY (there already is for AWSY). Of course that's not actually done yet, I just want to point out it's not particularly hard and AWSY's version could be adapted rather easily. 2. More hardware available, so can get results faster. I would guess we want to run on dedicated non-virtualized hardware for these tests. Is that an option w/ Talos? FWIW if that's an option I'd be more than happy to move AWSY over to the platform as well :) Talos already runs on non-virtualized hardware. I don't see any inherent reason we couldn't rework AWSY as a Talos test. In general it feels to me like we should be running performance tests on relops-supported infrastructure where possible, as opposed to adhoc systems. Thoughts? Incidentally one of my deliverables for this quarter is to try to figure out how Perfherder, Talos, and AWFY should co-exist, so I'm very interested in knowing if my assumptions above are correct. Regardless of whether we use Talos to run the tests or not, it would be definitely be nice have the data reported in perfherder. A digression, maybe worth followup in a separate thread: In general it would be great if we could consolidate the various perf tests (AWFY, AWSY, Talos, Raptor, etc) under one umbrella (at least from an end user perspective). So you could go to trychooser and choose a "Perf" option that would have various subsets like: "JS Engine", "Memory Usage", "Layout Latency", "Mobile Launch Time", etc. If all of these systems reported their data to perfherder (and optionally elsewhere) we'd now have one centralized location where you can track perf regressions. As an end-user this is pretty great: The graphs look the same across systems, I only have to learn how to use one tool, I only have to learn how to interpret regressions in one system. Yes, this seems like a good long-term goal to me. There are a few constraints that Perfherder has that make it unsuitable for some use cases: 1. It assumes that all test machines of a particular class will be uniform, at least per test. For example, Autophone tracks the performance of something like 9 different Android devices seperately (see: http://phonedash.mozilla.org/) -- that's not something Perfherder was designed to do. 2. It is designed to track performance changes in one product per repository, not compare one against another. It's not designed to facilitate comparisons between Firefox and Chrome. That shouldn't stop us from using Perfherder as at least an optional submission target for many systems though -- we've had good luck with autophone so far as a potential replacement for Android Talos on a single device class, and it looks like AWSY should work as well. AWFY is a bit of a different animal as it has its own regression detection/reporting system, in principle it makes sense to unify that with Perfherder but I'm not yet 100% sure what would be involved in making that happen -- AWFY supports some things that aren't on Perfherder's near-term roadmap (e.g. reporting a regression manually on an arbitrary revision), so we need to figure that out. Will ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
