Re: [webkit-dev] Fuzzy Reftest Plans, and Metadata Locations

2021-10-30 Thread Alejandro Garcia Castro via webkit-dev
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!


webkit-dev mailing list

Re: [webkit-dev] Concurrent display list item writing and reading in the GPU process

2020-10-30 Thread Alejandro Garcia Castro
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.



webkit-dev mailing list

Re: [webkit-dev] MathML layout refactor proposal

2015-12-28 Thread Alejandro Garcia Castro

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

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

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

Thanks again,

webkit-dev mailing list

Re: [webkit-dev] MathML layout refactor proposal

2015-12-14 Thread Alejandro Garcia Castro
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.

webkit-dev mailing list

[webkit-dev] MathML layout refactor proposal

2015-12-09 Thread Alejandro Garcia Castro


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

We have a working prototype that basically passes the current MathML
tests and removes the FlexBox dependency in:

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.


webkit-dev mailing list

Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl

2013-10-02 Thread Alejandro Garcia Castro
On Wed, Oct 02, 2013 at 09:49:23AM -0700, Anders Carlsson wrote:
 On Oct 1, 2013, at 11:29 PM, Sergio Villar Senin wrote:
  On 02/10/13 03:19, Anders Carlsson wrote:
  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
  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.

webkit-dev mailing list

Re: [webkit-dev] Todo List for WebKit2

2011-04-18 Thread Alejandro Garcia Castro
On Mon, Apr 18, 2011 at 06:08:33PM +0530, wrote:
 On Mon, Apr 18, 2011 at 5:37 PM, Balazs Kelemen wrote:
  On 04/14/2011 02:34 PM, 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:

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:

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:

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

Re: [webkit-dev] A question about new-run-webkit-tests

2011-03-18 Thread Alejandro Garcia Castro
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 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.

webkit-dev mailing list

Re: [webkit-dev] selecting text ignores mouse down position

2011-03-12 Thread Alejandro Garcia Castro
On Fri, Mar 11, 2011 at 01:43:25PM -0800, Evan Martin wrote:
 For those following at home, this moved to

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

webkit-dev mailing list

Re: [webkit-dev] Building WebKit's GTK+ back-end using distcc timing

2011-03-10 Thread Alejandro Garcia Castro
On Thu, Mar 10, 2011 at 11:55:15AM +0100, Ilyes Gouta wrote:
 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 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

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:

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

Re: [webkit-dev] More information for crashing tests now available on

2011-02-07 Thread Alejandro Garcia Castro
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,
 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:

webkit-dev mailing list

Re: [webkit-dev] Help with GTK build

2011-01-10 Thread Alejandro Garcia Castro
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:
  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:
webkit-dev mailing list

[webkit-dev] webkit-patch rebaseline problem

2010-12-07 Thread Alejandro Garcia Castro


does anyone know anything about this issue executing rebaseline?

xmlrpclib.ProtocolError: ProtocolError for 404 Not 


webkit-dev mailing list

[webkit-dev] WebKitGTK+ debug buildbots crash dumps

2010-04-17 Thread Alejandro Garcia Castro


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:

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?


webkit-dev mailing list