Re: [webkit-dev] Fuzzy Reftest Plans, and Metadata Locations
On Thu, Oct 28, 2021 at 06:24:02PM +0100, Sam Sneddon via webkit-dev wrote: > Hi! > > As part of the ongoing work on GPU Process, we’re interested in > adding support for reftest fuzzy matching (i.e., allowing a certain > amount of tolerance when comparing the generated images). > > [...] > > Finally, we could add per-test or per-directory files alongside > the tests. (Due to how things work, these could presumably also be > in directories in platform/.) This I think is probably the best > option as it keeps the metadata near the test, without needing to > modify the test (which, per above, is problematic for WPT as we > move to automatically exporting changes). One could imagine either > a __dir__-metadata.json (to use a similar name to how WPT names > directory-level metadata files) or a -expected-fuzzy.json file > alongside each test. > > Your opinions would be warmly welcomed! > Thanks for working on this, I can not provide any feedback on the solutions, but with regard to the situations that we would like to solve in WPE/GTK we need it. Some refrests will use it because depending on the layer structure the blurring algorithm used can be different and we found some of those when we activated async scrolling in the tests (I think Apple is currently not testing it this way). I guess that means we need a number per test for the solution, because the tests can be in different directories. I hope this information helps! Alex ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Concurrent display list item writing and reading in the GPU process
On Wed, Oct 28, 2020 at 05:14:58PM -0700, Wenson Hsieh wrote: > Hello webkit-dev! > > [...] > > While this email is mostly informative, we are also curious whether > this overall architecture will be compatible with non-Cocoa ports > (for instance, WPE and GTK), as most of our planning so far has been > done within the context of enabling GPU process for Cocoa platforms. > Thanks very much for the information, very interesting. We are interested in this feature and we want to add support for it in WPE and GTK ports. Hopefully we can allocate some time in the next months to make it happen, at this point we are still not sure about the main challenges though. We will try to keep you updated. br Alex ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] MathML layout refactor proposal
Hi Dave, thanks very much for your comments and feedback, this information is great to document the whole design process of the code. I agree with the goals you are pointing out, actually I think the change to use flexbox was a good option to try at that point. But currently considering the result of the design in the code we can see that the devil is in the detail. Trying to use box spacing to create complex anonymous render trees that produce the complex layout result of some mathml formula, brings a complex code difficult to improve to get the best math render possible. That is the main reason for this change, you can see bugs such as this were developers are not even sure how the whole layout is happening: https://bugs.webkit.org/show_bug.cgi?id=137330 The problem is worse if we try to add more complex layout calculations to match best formula rendering. Also we can find flexbox changes just avoiding mathml tests because it is not clear how the anonymous nodes structure is handled for some cases. So this takes us to the current proposal, if we do not get more feedback probably we will start asking for reviews in the next weeks, and we can discuss in more detail in the bugs the pros and cons of the change. Thanks again, Alex ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] MathML layout refactor proposal
On Mon, Dec 14, 2015 at 08:03:12PM +0100, Frédéric WANG wrote:
> Le 14/12/2015 19:39, Zalan Bujtas a écrit :
> > It’s great to hear that MathML is getting some proper cleanup. I think the
> > proposal sounds good and I am looking forward to the patches.
> >
> > Minor observation: I noticed that, since MathML block is no longer a
> > flexbox, but it still needs some of the flexbox functionality, the
> > following pattern has been introduced to the generic renderbox/block code.
> >
> > -if (parent()->isFlexibleBox()) {
> > +if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
> > I just wish there was another way to handle this.
> >
> > Zalan.
> Alex will correct me if I'm wrong, but I think the changes in RenderBox
> are just a temporary solution to avoid breaking tests while we continue
> to rewrite the MathML layout code. Hopefully, these won't be needed
> anymore when we are done.
>
Exactly, we need those to keep the width and height overrides working
like the flexbox did. This is the way layouts such us the flexbox or
the grid can force sizes in the children even if they do not request
it. Until we remove the old nodes structure in every renderer we have
to keep it, but I think we can remove all of them because MathML is
not a general layout so we control every layout and we can change its
size based on what their parent sets, even if that means using the
size of a sibling.
Alex
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] MathML layout refactor proposal
Hi, In the last months we have been working on refactoring the MathML layout code to make it more maintainable, because in the current point fixing issues or adding new features has been too complex. We have reached the point where we think we have to discuss whether this work makes sense and whether it is interesting for the WebKit community. If so, we will start pushing the initial patches from our branch to upstream. The idea behind the refactor is to remove FlexBox dependency and create its own layout MathML methods. The main reasons to do this are: - Reduce code complexity: Adapting FlexBox layout (which is already complex) in order to create the MahtML layout made the code too complex, a big technical debt that made the improvement of MathML more difficult every day. - Avoid just another FlexBox dependent code: When we had to add general layout alignment support we had a lot of problems trying to solve some the MathML issues because it was not clear how it worked with the FlexBox. - Improve performance: We do not need all the features FlexBox layout adds for most of the MathML blocks but we are executing all that code. We also can simplify the render tree structures that were created to make the FlexBox layout work. - Make easier to improve the MathML implementation: Using independent renderer classes gives more flexibility to get exact positioning and spacing required to get high-quality math rendering based on TeX rules and the OpenType MATH table. (cf http://www.mathml-association.org/MathMLinHTML5/) We have a working prototype that basically passes the current MathML tests and removes the FlexBox dependency in: https://github.com/alexgcastro/webkit/tree/MathMLLayout We have basically one commit per MathML renderer that we had to replace. This is still initial code and we need more work and add more tests to make sure we are improving the situation. We want to do it incrementally with 2 steps: 1. Remove FlexBox dependency but do not break the tests, this means keep the RenderTree structure. This is basically done, and we just need review and try to push them. 2. Refactor the RenderTree structure, removing the anonymous nodes created to make FlexBox work and all the code that it was required. We already have the Fractions and Underover implemented and the code is much clearer. This will break the tests relying on a PNG image or a render tree reference. Hence we will do it also per renderer and rebasing the tests after each commit. The main con of the change that the code could be bigger in some parts of the renderers, but more direct and simple, so it should be actually good regarding maintenance. If you have any question, proposal or comment just send it, it would be great to hear some more feedback, and check if we should proceed with this effort. Greetings, Alex ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl
On Wed, Oct 02, 2013 at 09:49:23AM -0700, Anders Carlsson wrote: On Oct 1, 2013, at 11:29 PM, Sergio Villar Senin svil...@igalia.com wrote: On 02/10/13 03:19, Anders Carlsson wrote: Hello, I just wanted to let everyone know that we (Apple) are moving away from DrawingAreaImpl and always using our tiled drawing area. Longer term we’d like to remove DrawingAreaImpl completely since it was designed back when we didn’t run in accelerated compositing mode all the time. It’s my understanding that all the other non-mac ports use coordinated graphics now, and so the logical step would be to create a special DrawingArea subclass for coordinated graphics and move the relevant code there. That’d allow us to remove DrawingAreaImpl and LayerTreeHost. GTK is not using coordinated graphics, we do WebProcess compositing. I see. Are you ever not in accelerated composited mode? Yes, we do enter accelerated composited mode when required, it is not activated all the time. I did not check that code in quite some time but we had planned to try a tiled solution at some point, we just did not have the time to do it up until now, your proposal is a good excuse to push the task. Regarding activating accelerated compositing all the time we will have to check if we have any users that would care about it, considering this is not going to happen tomorrow we can start with work and on the process check if we should add something. Please add me to any of the bugs you open and I'll try to check the code to help with that. Thanks for the heads up. Alex ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Todo List for WebKit2
On Mon, Apr 18, 2011 at 06:08:33PM +0530, naren.me...@gmail.com wrote: Hi, On Mon, Apr 18, 2011 at 5:37 PM, Balazs Kelemen kbal...@webkit.org wrote: On 04/14/2011 02:34 PM, naren.me...@gmail.com wrote: Hi Everybody, I have recently started understanding webkit2 and am interested in participating and contributing in this project. So far I have gone through the available webkit2 code through GIT repository and studied the available documents. I tried to find a ToDo list so that I can pick up some work from there but couldnt find it. Can any of you pls point me towards it, if its there ?? First of all, what platform are you targeting and what are your goals? I am currently trying to use WebKit2 engine (GTK port) to implement a full browser on linux, running on a dual core machine. Take care with using the current webkit2 gtk API, the API is still going to change in the future. Currently at least there are two bugs with API changes and there could be more in the future until there is an stable release: https://bugs.webkit.org/show_bug.cgi?id=57944 https://bugs.webkit.org/show_bug.cgi?id=57820 Best option to contribute to this port is that you hang around #webkit-gtk IRC channel (freenode) and ask about current situation in the implementation of any of the work you want to do, and use the webkitgtk mailinglist regarding this topic. Check the contribute setion of the webkitgtk webpage for details: http://webkitgtk.org/?page=contribute We are still adding basic core features because there are still things not working in the multiprocess architecture for GTK+, for instance we are still adding the testrunner: https://bugs.webkit.org/show_bug.cgi?id=57068 You can apply that patch and try to help fixing the features required to make all the tests that are running for webkit1 work. Any patch and proposal is welcome :). I hope I answered the webkit2gtk+ part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
On Fri, Mar 18, 2011 at 02:25:21PM -0700, Mark Rowe wrote: On 2011-03-18, at 14:22, Dirk Pranke wrote: * There are GTK bots that run NRWT as well as the Chromium bots Where? None of the bots on build.webkit.org use it as far as I can tell. And the run-webkit-tests script contains the following: We added the support for GTK and I use it locally sometimes but we are still not using it in the bots AFAIK. br ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] selecting text ignores mouse down position
On Fri, Mar 11, 2011 at 01:43:25PM -0800, Evan Martin wrote: For those following at home, this moved to https://bugs.webkit.org/show_bug.cgi?id=56213 Hi Evan, I've tried to fix this issue long time ago in this bug, feel free to dup it with your new bug as I did not spend time on the issue in a long time: https://bugs.webkit.org/show_bug.cgi?id=31711 HIH ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building WebKit's GTK+ back-end using distcc timing
On Thu, Mar 10, 2011 at 11:55:15AM +0100, Ilyes Gouta wrote: Hi, [...] Could some one enlighten us about what have changed in the build system of the Gtk+ port of WebKit that would have an impact on the total build time? Could it be that configure.ac has changed so that the final generated GNUMakefile is less optimal and spends more time doing something else, when going through the CXX files to compile them? I think after that commit (if I checked it correctly it was 1 year ago) a lot things have changed and I do not think there is just one patch to blame, probably just the additions of new files to the compilation after that commit could be increasing the time. I've also noticed compilation is slower since 1 year ago, but I do not think it has been just one patch the reason. Anyway the main change lately in the compilation system has been this: http://trac.webkit.org/changeset/75362 But not sure if that could cause such a big impact in your distcc compilation, you can try to check it. I hope this helps. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More information for crashing tests now available on build.webkit.org
On Fri, Feb 04, 2011 at 02:25:10PM -0500, Adam Roben wrote: Hi all- [...] Please file any bugs you find with this feature on bugs.webkit.org, and CC me. Please also file bugs for any ideas you have for making this more useful! Nice, we have been running this crash service for the two gtk+ debug bots for some time now, it has stacks and core files, maybe it is a good idea if we could also integrate it the same way, if possible: http://webkit-bots.igalia.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with GTK build
On Sat, Jan 08, 2011 at 12:50:11PM +0100, Alejandro G. Castro wrote: On Sat, Jan 08, 2011 at 12:20:18PM +0100, Alejandro G. Castro wrote: [...] Yeah, it is the length, we already had that issue when doing make dist. It looks like adding Source is adding enough characters to cause the same problem: http://thread.gmane.org/gmane.comp.gnu.make.bugs/4219 I'm afraid we have to patch the make we are using in the bots. I'll try to check it. I've patched and installed the make package in the 64bits debug bot and apparently it is working, I'm going to do the same in the 32bit debug, unfortunately I do not have access to the release bots. For the record, Xan and Martin just committed the required fix, so we do not need to patch make: http://trac.webkit.org/changeset/75362 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit-patch rebaseline problem
Hi, does anyone know anything about this issue executing rebaseline? xmlrpclib.ProtocolError: ProtocolError for build.webkit.org/xmlrpc: 404 Not Found br ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKitGTK+ debug buildbots crash dumps
Hi, we have installed a crash dumps analysis to the WebKitGTK+ debug bots, this way it is easier to check what has failed when a test crashes inside the bots. It has already gave us good information about flacky tests root causes. You can check it here: http://webkit-bots.igalia.com/ We are planning to add the name of the test failing to the information. Maybe it is a good idea to add this kind of service to the buildbot page someway? br ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
