[webkit-dev] Layout tests

[Ronan Meneu]

I have managed to write a DumpRenderTree from the GdkLauncher. On few
examples, it looks like results are very similar : differences are in the
text size, due to the font differences, but trees are nearly matching those
expected !
With a few adaptation of the run-webkit-tests scripts, i am able to execute
series of tests. So it seems to be a good start.

The technical points i have to resolved now are :
   * the notification of the "loaded" state. In the .m files, it's done with
some delegates. Is there a way of getting this event in webcore, on the
frame or frameview interface, for instance ? I have looked for
registration/delegation/event patterns but could not find a direct solution.
   * the LayoutTestController : i suppose i have to rewrite it in C++, in a
binding js object, if i want to pass test that uses the
"waituntildone/notifyDone" behaviour. Am i right ?

Thanks,

  Ronan

On 7/4/06, Mike Emmel < mike.emmel at gmail.com> wrote:
>
> Sorry one more post my suggestion for running the layout tests sooner
> then later is
> to use the gdk port to OSX its in the gnome CVS.
>
> You should be able to use the freetype backend. At that point
> differences are very minimal
> and at the cairo level if at all and these is more a issue of testing
> cross platform issues
> in cairo itself this should be small.
>
> This gives you the needed NSView from the GdkWindow.
> One of the big reasons I chose gdk actually since I can run in with minor
> work
> on OSX/Win32/Linux.
>
> Mike
>
>
>
>
> On 7/4/06, Mike Emmel <mike.emmel at gmail.com> wrote:
> > On 7/4/06, Eric Seidel <macdome at opendarwin.org > wrote:
> > >
> > > On Jul 4, 2006, at 1:35 PM, Mike Emmel wrote:
> > > >
> > > > So  why run the layout tests now ?
> > > > The current ports problems are evident via simple single page
> testing.
> > >
> > > Layout tests are always useful.  Even if the port is otherwise non-
> > > functional, the layout tests will help you better understand your
> > > changes, when you make them.  Sometimes you'll make a one line change
> > > and change (fix or break) tens or hundreds of tests at once.
> > >
> >
> > I don't disagree that there not useful if it was a simple matter to
> > get them to run.
> > But it looks like a pretty big project which may not complete for some
> time.
> > Which brings up a number of questions.
> > Is this the best test code base for cross platform testing ?
> >
> > There are other tests suites acid2 I believe that may be more amendable.
> > In anycase there are a lot of testing frameworks out ther.
> >
> > Again I'm just questioning the timing and scope of the project.
> >
> > Not that it would not be useful if it was available.
> >
> > Mike
> >
> >
> >
> >
> > > On 7/4/06, Ronan Meneu < rmeneu at origyn.fr> wrote:
> > > > * I have compiled the DumpRenderTree tool in the .vcproj, modified
> > > > it to
> > > > build a FrameGdk instead of a FrameWin. Purpose of this tool i
> > > > think is to
> > > > just dump render tree. It does not have some functionalities of the
> > > > objective-c code like "image diff". It works on linux, but layer
> > > > size is
> > > > always 0x0. Is this the DumpRenderTree tool used on win32 platform ?
> > >
> > > This is the correct direction to move in.  DumpRenderTree.cpp just
> > > hasn't received enough lovin yet.
> > >
> > > An ambitious coder might chose to try and port more of
> > > DumpRenderTree.xcodeproj (all the associated .m files) to c++ to be
> > > shared.  It's probably just as easy to write new .cpp files however.
> > > Especially since it will be a long time before any sort of delegation
> > > model (for editing, loading delegates, etc.) exists for WebKit for
> > > any platform other than OS X.
> > >
> > > ImageDiff would be simple enough to write using ImageMagick, or any
> > > other image library which knew how to read pngs into an RGBA array.
> > >
> > > One of the first problems someone needs to solve, is setting up run-
> > > webkit-tests to dump separate -expected.txt files for windows or find
> > > some way of comparing windows/linux expected.txt output with mac
> > > expected.txt output.  This is likely impossible due to different
> > > fonts on the three systems.
> > >
> > > Happy hacking.
> > >
> > > -eric
> > >
> >
>



-- 
Ronan Meneu
Origyn Web Browser for Embedded Systems Team
Senior Software Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060706/2328fa9a/attachment.html