Hello, I would like to compile and run layout tests on a linux machine. I have several ways to follow, but i am not sure of the best one : * I have tried to compile DumpRenderTree (objective-c code). Using GNUstep, i can resolve most of the missing headers and objects. I still have few compilation errors. Do you think it's worth going on, or is it to close to some Apple tools to get it running on a linux platform ? * 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 ? * Another solution is to port objective-c code in C++. It seems to me that it is quite complex. Has anyone tried to do this ? Have you got some advice to realize it ? Thanks for your help, -- Ronan Meneu Origyn Web Browser for Embedded Systems Team Senior Software Engineer
On 7/4/06, Ronan Meneu <rmeneu@origyn.fr> wrote:
Hello,
I would like to compile and run layout tests on a linux machine. I have several ways to follow, but i am not sure of the best one :
* I have tried to compile DumpRenderTree (objective-c code). Using GNUstep, i can resolve most of the missing headers and objects. I still have few compilation errors. Do you think it's worth going on, or is it to close to some Apple tools to get it running on a linux platform ?
* 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 ?
The Gdk port is driven from bakefiles here is a short set of build instructions. 1.) Install any missing librarires the depends can be read out of Bakefiles/presets.bkl look for pkg-config also you need the bakefile tool. http://bakefile.sourceforge.net cd Bakefile bakefile_gen cd JavaScriptCore make cd WebCore/Projects/gdk make cvs WebKitTools/GdkLauncher bakefile_gen make ./gdklauncher [url] I've not looked at how the layout test work yet the current port has a number of issues. Text input fields are not working correctly ( there platform independent) Selection is broken Highlight on scroll is broken Post and other features of http not supported. And a lot more. Since the layout code is shared I don't personally see that the tests are that useful at this time at least till the linux port is more complete. Most of the cairo code is shared with the windows port the only place that layout is really platform independent is with the fonts and this seems okay. So why run the layout tests now ? The current ports problems are evident via simple single page testing. Mike
* Another solution is to port objective-c code in C++. It seems to me that it is quite complex. Has anyone tried to do this ? Have you got some advice to realize it ?
Thanks for your help,
-- Ronan Meneu Origyn Web Browser for Embedded Systems Team Senior Software Engineer _______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
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. On 7/4/06, Ronan Meneu <rmeneu@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
On 7/4/06, Eric Seidel <macdome@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@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
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@gmail.com> wrote:
On 7/4/06, Eric Seidel <macdome@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@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
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@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@gmail.com> wrote:
On 7/4/06, Eric Seidel <macdome@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@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
participants (3)
-
Eric Seidel
-
Mike Emmel
-
Ronan Meneu