[webkit-dev] Running webkit tests on windows
I've been trying to get the webkit tests running on windows...I'm pretty close
and a lot of the tests are passing however, it looks like I have a problem with
several at the moment because of what I think may be an issue with fonts.
I've followed the directions for getting fonts at
http://trac.webkit.org/wiki/BuildingOnWindows (which seems to have an issue
because the ttc files don't quite decompress the Lucida Grande mac ttc file for
me; so I had to get it from somewhere else). I'm not sure if this is my
problem though; but I do have Lucida Grande and Lucida Grande Bold fonts (just
not the ones from my mac). I've stepped through the DumpRenderTree code and
I've seen it register all the fonts successfully in
WebTextRenderer::registerPrivateFont and it seems to be ok.
However, when I run the tests it seems to fail for the sans-serif font areas.
Here's one of my failures below. Does someone know which font this test uses
for sans-serif and where I can get it from since I'm guessing I have the wrong
one.
Is there some way to know which fonts are used in text runs or is there a good
breakpoint I can set somewhere to figure this out?
e.g. this line shows a different width for the text run:
- text run at (0,3) width 348: This element should be in a sans-serif
font.
+ text run at (0,3) width 375: This element should be in a sans-serif
font.
Here's my full test failure for css1/font_properties/font.html
--- /tmp/layout-test-results/css1/font_properties/font-expected.txt
2010-04-07 17:31:03.720919800 -0700
+++ /tmp/layout-test-results/css1/font_properties/font-actual.txt 2010-04-07
17:31:03.720919800 -0700
@@ -48,12 +48,12 @@
text run at (423,29) width 297: Extra text is included for the
purposes of
text run at (0,56) width 208: testing this more effectively.
RenderBlock {P} at (0,388) size 769x81
-RenderText {#text} at (0,3) size 760x75
- text run at (0,3) width 348: This element should be in a sans-serif
font.
- text run at (348,3) width 412: Its font-size should be 150% the
base font size, and
- text run at (0,30) width 568: its line-height should 150% of that
value (18px and 27px, respectively).
- text run at (568,30) width 192: Extra text is included for
- text run at (0,57) width 351: the purposes of testing this more
effectively.
+RenderText {#text} at (0,3) size 734x75
+ text run at (0,3) width 375: This element should be in a sans-serif
font.
+ text run at (375,3) width 358: Its font-size should be 150% the
base font
+ text run at (0,30) width 689: size, and its line-height should 150%
of that value (18px and 27px, respectively).
+ text run at (689,30) width 45: Extra
+ text run at (0,57) width 548: text is included for the purposes of
testing this more effectively.
RenderBlock {P} at (0,487) size 769x78
RenderText {#text} at (0,2) size 762x47
text run at (0,2) width 628: This element should be in a cursive
font, 'small' in size, with a line-height 200% the height of the text's actual
size.
@@ -106,10 +106,11 @@
text run at (176,79) width 500: Extra text is included for the
purposes of testing this more
text run at (0,115) width 93: effectively.
RenderBlock {P} at (0,1519) size 769x50
-RenderText {#text} at (0,6) size 751x37
- text run at (0,6) width 301: This element should be in a sans-serif
font, with a weight of 400.
- text run at (301,6) width 450: Its font-size should be 80% of 12px,
or 10px, and its line-height shoud be 2.5 times that, or 25px.
- text run at (0,31) width 318: Extra text is included for the
purposes of testing this more effectively.
+RenderText {#text} at (0,6) size 756x37
+ text run at (0,6) width 317: This element should be in a sans-serif
font, with a weight of 400.
+ text run at (317,6) width 439: Its font-size should be 80% of 12px,
or 10px, and its line-height shoud be 2.5 times that, or
+ text run at (0,31) width 30: 25px.
+ text run at (30,31) width 341: Extra text is included for the
purposes of testing this more effectively.
RenderBlock {P} at (0,1587) size 769x216
RenderInline {SPAN} at (0,0) size 765x183 [bgcolor=#C0C0C0]
RenderText {#text} at (0,16) size 765x183
@@ -148,13 +149,13 @@
text run at (138,76) width 563: Extra text is included for
the purposes of testing this more
text run at (0,112) width 111: effectively.
RenderBlock {P} at (4,269) size 747x144
-RenderText {#text} at (0,4) size 733x136
- text run at (0,4) width 461: This element should be in a
sans-serif font.
- text run at (461,4) width 232: Its font-size should be
-
[webkit-dev] Windows mobile build
Right now we have a windows mobile 6.x build for webkit. I'd like to start merging this into the tree but wanted to get some consensus on an approach. We have created our own solution and vcproj files that pretty much follow the current solution/vcproj files for the windows cairo build configuration. Would it make sense to add a windows mobile build and solution configuration to the existing windows solution (with some different vsprop changes) or should we check in our version of the solution and project files separately (and where?) I don't like the idea of a separate solution/vcproj files but as far as I know if we add the windows mobile configuration you need to have the windows mobile sdk installed to be able to open the solution. I need to confirm that this is true also if you just run the build from the command line though. I've had some success merging changes between vcproj files so it's possible this might be automated. Thanks, Jason. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Windows mobile build
That's great news... How far away are you from getting this build toolchain working? I want to upstream the API once I work out how we can integrate our changes; which I think means that first we need a build environment that can build our changes. We are still working on the LayoutTests right now so I'm not sure. -Original Message- From: KwangYul Seo [mailto:kwangyul@gmail.com] Sent: Friday, April 02, 2010 10:46 AM To: Jason Rukman Cc: Webkit Development List Subject: Re: [webkit-dev] Windows mobile build Hi, Jason. I don't think it is a good idea to add separate solution and vcproj files for Windows Mobile. Windows Mobile is just a small part of Windows CE. Windows CE covers multiple CPU architectures (ARM, MIPS, ..) and platforms with varying features. I hope the build system covers multiple configurations easily. vcproj file is too verbose and not easy to maintain to keep multiple configurations as we can see from Windows port. If we are going to add a build system for Windows CE, I think we need a more clever way to deal with this problem. I am currently working on a build system which generates MSVS solution and vcproj files from a build script. The sole purpose of this build system is to support multiple Windows CE platforms and configurations from a single script. I'd like to contribute this work once it is ready. By the way, what is your contribution plan? Do you plan to contribute WebKit API and layout tests? Regards, Kwang Yul Seo On Sat, Apr 3, 2010 at 12:45 AM, Jason Rukman jas...@bsquare.com wrote: Right now we have a windows mobile 6.x build for webkit. I’d like to start merging this into the tree but wanted to get some consensus on an approach. We have created our own solution and vcproj files that pretty much follow the current solution/vcproj files for the windows cairo build configuration. Would it make sense to add a windows mobile build and solution configuration to the existing windows solution (with some different vsprop changes) or should we check in our version of the solution and project files separately (and where?) I don’t like the idea of a separate solution/vcproj files but as far as I know if we add the windows mobile configuration you need to have the windows mobile sdk installed to be able to open the solution. I need to confirm that this is true also if you just run the build from the command line though. I’ve had some success merging changes between vcproj files so it’s possible this might be automated. Thanks, Jason. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Windows mobile build
I haven't looked at any other build solutions as the vcproj files have been working for us at the moment. I would think leveraging an existing build configuration would be best though. From: le...@google.com [mailto:le...@google.com] On Behalf Of David Levin Sent: Friday, April 02, 2010 11:43 AM To: KwangYul Seo Cc: Jason Rukman; Webkit Development List Subject: Re: [webkit-dev] Windows mobile build KwangYul, have you considered using gyp (and the files already there) rather than add another generating solution? Jason, have you considered using gyp to generate your solution? Disclaimer: I have no stake in gyp nor do I think it is necessarily better than anything else, but I do care about not modifying 7+ build files for any file additions/moves, etc. dave On Fri, Apr 2, 2010 at 10:50 AM, Jason Rukman jas...@bsquare.com wrote: That's great news... How far away are you from getting this build toolchain working? I want to upstream the API once I work out how we can integrate our changes; which I think means that first we need a build environment that can build our changes. We are still working on the LayoutTests right now so I'm not sure. -Original Message- From: KwangYul Seo [mailto:kwangyul@gmail.com] Sent: Friday, April 02, 2010 10:46 AM To: Jason Rukman Cc: Webkit Development List Subject: Re: [webkit-dev] Windows mobile build Hi, Jason. I don't think it is a good idea to add separate solution and vcproj files for Windows Mobile. Windows Mobile is just a small part of Windows CE. Windows CE covers multiple CPU architectures (ARM, MIPS, ..) and platforms with varying features. I hope the build system covers multiple configurations easily. vcproj file is too verbose and not easy to maintain to keep multiple configurations as we can see from Windows port. If we are going to add a build system for Windows CE, I think we need a more clever way to deal with this problem. I am currently working on a build system which generates MSVS solution and vcproj files from a build script. The sole purpose of this build system is to support multiple Windows CE platforms and configurations from a single script. I'd like to contribute this work once it is ready. By the way, what is your contribution plan? Do you plan to contribute WebKit API and layout tests? Regards, Kwang Yul Seo On Sat, Apr 3, 2010 at 12:45 AM, Jason Rukman jas...@bsquare.com wrote: Right now we have a windows mobile 6.x build for webkit. I'd like to start merging this into the tree but wanted to get some consensus on an approach. We have created our own solution and vcproj files that pretty much follow the current solution/vcproj files for the windows cairo build configuration. Would it make sense to add a windows mobile build and solution configuration to the existing windows solution (with some different vsprop changes) or should we check in our version of the solution and project files separately (and where?) I don't like the idea of a separate solution/vcproj files but as far as I know if we add the windows mobile configuration you need to have the windows mobile sdk installed to be able to open the solution. I need to confirm that this is true also if you just run the build from the command line though. I've had some success merging changes between vcproj files so it's possible this might be automated. Thanks, Jason. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Frustrations with WebKit Font Representation
I'd say for our configuration that uses wince/cairo and rendering with freetype that this is a welcome move as we've been working with this font configuration between cairo and windows CE and copying the gtk code over manually for now to get it working. I haven't yet integrated this change into our tree though so I'll wait and see what happens when we have to do that. -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Brent Fulgham Sent: Tuesday, March 16, 2010 3:50 PM To: Webkit Development List Subject: [webkit-dev] Frustrations with WebKit Font Representation Recently, an update that attempted to share more Cairo-related font code was added to the WebKit repository (http://trac.webkit.org/changeset/55510). While this was no doubt of great benefit to the Gtk-based ports, it had the unintended side effect of breaking the WinCairo port, as it placed a FontPlatformData.h file (which had previously been hidden in a platform-specific gtk directory) into the Cairo directory. This file was set up to support Pango or FreeType as rendering backends, and so failed when attempting to build using the WinCairo GDI-based backend. My initial thought was to simply copy the salient elements from the win/FontPlatformData.h file (shared between the Windows CG-based and Cairo-based builds) into the new cairo/FontPlatformData.h. However, this will probably make it easier for the CG port to drift out of sync with the WinCairo port, creating maintenance difficulty. After all, I mostly want to replicate the way Apple's CG port works with fonts, the only fundamental difference being that WinCairo performs rendering of the GDI fonts via the Cairo library, while Apple's CG port naturally uses the CoreGraphics library for its drawing. After discussing the issue with Adam Roben for a bit, he made the excellent observation that the main problem was that the FontPlatformData type was providing the wrong layer of abstraction. It has morphed into an object type that attempts to encapsulate both the underlying operating system's concept of a font/glyph (e.g., GDI, FreeType, Pango, etc.) and the mechanism used to render the font to screen (e.g., Cairo, CoreGraphics, Skia, etc.). The various ports have managed to cobble together a system that works, but in the process have created a Byzantine structure full of duplicated file names (FontPlatformData.h, FontCustomPlatformData.h, etc. for each platform) that generally expose incompatible API's and data structures. Based on the existing implementation, I wonder if a better approach might be possible that would separate the rendering process from the underlying font representation. That way, a Windows application using GDI fonts with a cairo rendering layer could largely share the same underlying font representation with a CoreGraphics. Similarly, all ports built on top of Cairo could use different font representations (e.g., GDI, Pango, FreeType) but still pipe the drawing logic through the Cairo layer. Has anyone else run into these kinds of issues, and might have some suggestions for how to better approach this problem? Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font layout features
Any pointers at all would be greatly appreciated! -Original Message- From: Jason Rukman Sent: Wednesday, January 20, 2010 9:49 AM To: webkit-dev@lists.webkit.org Subject: Font layout features As part of our port to windows CE we are using a Cairo configuration combined with freetype. This is fairly similar to the Windows port but we are not using the native Windows GDI/cairo layer for fonts (instead we are using cairo-ft). However, unlike the GTK port, we did not port Pango, and so are using Cairo font layout. Can someone comment on what limitation we may have with Asian fonts/glyphs or other issues with this configuration? We have ported the latest versions of freetype, fontconfig and cairo to CE. Thanks, Jason. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font layout features
Thanks for the reply Evan!
We are using the same code as the windows Cairo port for glyph rendering so
FontCairo which only uses cairo_show_glyphs.
The only difference is that our port of Cairo is using cairo-ft instead of
cairo-win32-font and we've brought the freetype font support over from the gtk
port.
I guess my main question is; What does pango do for the gtk port? Do I need
to worry that we are not using it and just using freetype?
We have the layout tests running but at this point we aren't running the pixel
tests; is this necessary for the text rendering tests to show up issues or will
we be hitting the necessary tests without them?
I've been working to get our tree in a state we can open it up; I'm sorry I'm
not quite there yet.
Here's one stack trace that hits cairo_show_glyphs:
WebKit.dll!cairo_show_glyphs(_cairo* cr = 0x011836e0, cairo_glyph_t*
glyphs = 0x0011baf0, int num_glyphs = 18) Line: 3162, Byte Offsets: 0x10 C
WebKit.dll!WebCore::Font::drawGlyphs(WebCore::GraphicsContext* context
= 0x0012f700, WebCore::SimpleFontData* font = 0x00c58380, WebCore::GlyphBuffer
glyphBuffer = {...}, int from = 0, int numGlyphs = 18, WebCore::FloatPoint
point = {...}) Line: 152, Byte Offsets: 0x7c0C++
WebKit.dll!WebCore::Font::drawGlyphBuffer(WebCore::GraphicsContext*
context = 0x0012f700, WebCore::GlyphBuffer glyphBuffer = {...},
WebCore::TextRun __formal = {...}, WebCore::FloatPoint point = {...}) Line:
316, Byte Offsets: 0x1ac C++
WebKit.dll!WebCore::Font::drawSimpleText(WebCore::GraphicsContext*
context = 0x0012f700, WebCore::TextRun run = {...}, WebCore::FloatPoint point
= {...}, int from = 0, int to = 18) Line: 289, Byte Offsets: 0x26c C++
WebKit.dll!WebCore::Font::drawText(WebCore::GraphicsContext* context =
0x0012f700, WebCore::TextRun run = {...}, WebCore::FloatPoint point = {...},
int from = 0, int to = 18) Line: 179, Byte Offsets: 0x118 C++
WebKit.dll!WebCore::GraphicsContext::drawText(WebCore::Font font =
{...}, WebCore::TextRun run = {...}, WebCore::IntPoint point = {...}, int
from = 0, int to = 18) Line: 338, Byte Offsets: 0x5cC++
WebKit.dll!WebCore::paintTextWithShadows(WebCore::GraphicsContext*
context = 0x0012f700, WebCore::Font font = {...}, WebCore::TextRun textRun =
{...}, int startOffset = 0, int endOffset = 18, int truncationPoint = 18,
WebCore::IntPoint textOrigin = {...}, int x = 8, int y = 19, int w = 193, int
h = 28, WebCore::ShadowData* shadow = 0x, bool stroked = false) Line:
308, Byte Offsets: 0x258 C++
WebKit.dll!WebCore::InlineTextBox::paint(WebCore::RenderObject::PaintInfo
paintInfo = {...}, int tx = 8, int ty = 19) Line: 499, Byte Offsets: 0x1084 C++
WebKit.dll!WebCore::InlineFlowBox::paint(WebCore::RenderObject::PaintInfo
paintInfo = {...}, int tx = 8, int ty = 19) Line: 677, Byte Offsets: 0x42c C++
WebKit.dll!WebCore::InlineFlowBox::paint(WebCore::RenderObject::PaintInfo
paintInfo = {...}, int tx = 8, int ty = 19) Line: 677, Byte Offsets: 0x42c C++
WebKit.dll!WebCore::RootInlineBox::paint(WebCore::RenderObject::PaintInfo
paintInfo = {...}, int tx = 8, int ty = 19) Line: 167, Byte Offsets: 0x20C++
(tons more removed)
Thanks again,
Jason.
-Original Message-
From: ev...@google.com [mailto:ev...@google.com] On Behalf Of Evan Martin
Sent: Thursday, January 21, 2010 9:17 AM
To: Jason Rukman
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Font layout features
On Wed, Jan 20, 2010 at 9:49 AM, Jason Rukman jas...@bsquare.com wrote:
As part of our port to windows CE we are using a Cairo configuration combined
with freetype. This is fairly similar to the Windows port but we are not
using the native Windows GDI/cairo layer for fonts (instead we are using
cairo-ft). However, unlike the GTK port, we did not port Pango, and so are
using Cairo font layout. Can someone comment on what limitation we may have
with Asian fonts/glyphs or other issues with this configuration? We have
ported the latest versions of freetype, fontconfig and cairo to CE.
It is difficult to answer your question, because it depends on what
you are doing. Where is the code?
cairo_show_text() is the API to take pause at:
http://www.cairographics.org/manual/cairo-text.html#cairo-show-text
Note: The cairo_show_text() function call is part of what the cairo
designers call the toy text API. It is convenient for short demos
and simple programs, but it is not expected to be adequate for serious
text-using applications. See cairo_show_glyphs() for the real text
display API in cairo.
But I guess you must be doing some sort of interfacing with Freetype
because WebKit wants glyph extents, etc, which makes me guess you're
using a lower layer.
In general, you can gain or lose confidence in the quality of your
port by running the layout tests. If there are any text rendering
problems that you see that aren't covered
Re: [webkit-dev] Font layout features
I'm also using icu... does this mean I should be ok? -Original Message- From: ev...@google.com [mailto:ev...@google.com] On Behalf Of Evan Martin Sent: Thursday, January 21, 2010 10:41 AM To: Jason Rukman Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Font layout features On Thu, Jan 21, 2010 at 10:23 AM, Jason Rukman jas...@bsquare.com wrote: I guess my main question is; What does pango do for the gtk port? Do I need to worry that we are not using it and just using freetype? Complex text. Without Pango or Harfbuzz or ICU you won't properly display Arabic, Hebrew, Indic scripts, and strange combinations of more ordinary letters involving combining characters m plus acute. CJK ought to work though. We have the layout tests running but at this point we aren't running the pixel tests; is this necessary for the text rendering tests to show up issues or will we be hitting the necessary tests without them? Some layout tests may catch some of these issues, but you probably need pixels to verify the actual scripts come out ok. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font layout features
Just to clarify. Using freetype with ICU alone isn't sufficient without pango or harfbuzz for Arabic et al? -Original Message- From: ev...@google.com [mailto:ev...@google.com] On Behalf Of Evan Martin Sent: Thursday, January 21, 2010 10:45 AM To: Jason Rukman Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Font layout features On Thu, Jan 21, 2010 at 10:42 AM, Jason Rukman jas...@bsquare.com wrote: I'm also using icu... does this mean I should be ok? I meant ICU for shaping. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Font layout features
As part of our port to windows CE we are using a Cairo configuration combined with freetype. This is fairly similar to the Windows port but we are not using the native Windows GDI/cairo layer for fonts (instead we are using cairo-ft). However, unlike the GTK port, we did not port Pango, and so are using Cairo font layout. Can someone comment on what limitation we may have with Asian fonts/glyphs or other issues with this configuration? We have ported the latest versions of freetype, fontconfig and cairo to CE. Thanks, Jason. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Scrolling / redraw issue on WinCE platform
Hi Brent, Actually SetGraphicsMode is not available at all on WinCE so I've disabled this in a number of places; however, I've also tested that none of these disabled locations are being hit at this point. How did you find out these places where the World Transform (XFORM) didn't match up? I'd like to try find the same thing. Thanks for the idea! Regards, Jason. -Original Message- From: Brent Fulgham [mailto:bfulg...@gmail.com] Sent: Monday, January 11, 2010 9:48 AM To: Jason Rukman Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Scrolling / redraw issue on WinCE platform Hi Jason, On Fri, Jan 8, 2010 at 11:14 AM, Jason Rukman jas...@bsquare.com wrote: I'm working on a port of webKit to WinCE, and am currently encountering what appears to be a redraw/paint issue when scrolling (horizontally, in this case) to a widget that is originally partially off-screen (an input button in a form). The text all appears to scroll just fine, and the image of the start of the button (which is initially on screen) is moved correctly as well through the backingStore. However, when a paintButton is issued, the button appears in the same location on the screen post-scroll as it does pre-scroll, i.e. in the same position and still partially off the screen, even though the rest of the screen has scrolled. I haven't looked at your code, but on the Windows Cairo port I have run into several cases where the GDI World Transform has not been kept in sync with the additional graphics libraries used to draw widgets. For example, I ran into some cases where the XFORM was not updated for some drawing, even though the Cairo graphics context was adjusted to take into account translation or scaling effects. It could be that your port (which probably uses *only* GDI) may be touching an area of code where some kind of coordinate transform is needed, but has not been handled at the root XFORM level, relying on CoreGraphics, Cairo, etc., to actually shift the drawing context in some fashion before drawing. Oh, there were a few places where the SetGraphicsMode(dc, GM_ADVANCED) was needed to ensure that coordinate transforms were being honored. Just my quick 2 cents, but might be a good place to start. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Scrolling / redraw issue on WinCE platform
I'm working on a port of webKit to WinCE, and am currently encountering what appears to be a redraw/paint issue when scrolling (horizontally, in this case) to a widget that is originally partially off-screen (an input button in a form). The text all appears to scroll just fine, and the image of the start of the button (which is initially on screen) is moved correctly as well through the backingStore. However, when a paintButton is issued, the button appears in the same location on the screen post-scroll as it does pre-scroll, i.e. in the same position and still partially off the screen, even though the rest of the screen has scrolled. I'm looking for someone that can help debug this a bit further; hopefully can someone point me at some places to break and look to see which values are being set wrong and why; or if you'd like some specific stack traces I can get those too. I've tracked the code from WebView::scrollBackingStore (where the correct dx,dy values are being used to scroll the entire screen), through WebView::updateBackingStore, through paint code in RenderBlock, into RenderTheme and finally RenderThemeWin::paint (and subsequently paintButton). At this last stage, the x,y,width,height values for my button are still holding their original values (positioning the button partially offscreen in its initial paint), which I believe is correct. drawControl in RenderThemeWin is called, which ends up at DrawFrameControl. However, at this point, the paint still positions the button incorrectly. It is interesting to note that button's text IS positioned correctly after the scroll, however the frame of the button is not. I've downloaded and built webkit in safari, stepped through and verified this code works correctly on a pc and screen coords, etc are the same, so I suspect the culprit is WinCE-specific code, however I've been unable to get further. The html that produces this behavior is: table form id=one method=post action=/ tr td nobr Much more text here to offset the whole input field area and require scrolling. It looks like more and more is why input type=submit value=Submit More Please! / And read this! /nobr /td /tr /form /table I can also send in some screen shots of the issue but I wasn't sure if this mailing list supported that. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build system for wince port
Hi Patrick, We have a working wince build for all components right now including javascrtipcore, webcore and webkit COM layers. We'd like to help contribute this back in as well and work together with you on this. Right now we are using a separate vcproj file for each of the components (solution 1(b) below). Our build is a wince-cairo configuration and follows the windows build configuration very closely so we are not dependent on a lot of the current WINCE files in the tree (in fact I don't think we are using almost any of these except in a couple of places). We'd like to contribute this back using a new build flag such as WINCE_CAIRO. Best regards, Jason -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Patrick Roland Gansterer Sent: Wednesday, December 23, 2009 5:41 PM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] build system for wince port Currently the Windows CE port has no working build system. I'd like to contribute one, but i need to know the preferred solution: (1) Add the port to the current sln/vsproj/vsprops files a) Extend the sln/vsproj with the additional platforms and add many FileConfiguration ExcludedFromBuild=true and split the vspops. b) Add a separate main vsproj file (JavaScriptCore.vcproj, WebCore.vcproj) for the port (like code.staikos.net) c) Split the current main vspoj files into a platform dependent and independent file (2) Add it to a other build system like gyp or bkl. Which one provides good cross compiling features for wince? (3) Add a completely independent build system Which one is the least ugly one? I prefer 1a in the moment. I'd like to start with STANDARDSDK_500 (ARMV4I) and then add other supported STANDARDSDK_500 platforms. Because the wince port isn't finished right now, it's only possible to provide it for WTF and JavaScriptCore (including tests). Is already anything in the repository with support for cross compiling (something like Scripts/build-webkit)? Is anybody _active_ working on the wince port? Most of the related bugs are inactive for months now. Does anybody have the last git repository form git://code.staikos.net/WebKit- CE before it has gone offline? (my last log message is from 2009-07-30) I'd like to do some additional work in porting the remaining parts, when i have a working build system for it. - Patick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JIT on Windows CE
Hi İsmail, I’ve tried to get JIT working a couple of times on our wince build but with limited success. There’s some strangeness going on with the crossover of arguments from the wince compiler toolchain through to the JIT code (probably with the stack frame or something like that). My debug builds seem to run more reliably (it does crash as well eventually) but as soon as I try this same thing on a release build it blows up pretty quickly in the JITted code; the crashes are rather non-deterministic. I’m suspicious that ctiTrampoline needs some modifications that I haven’t been able to determine for it to work reliably on wince. Jason. From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Ismail Dönmez Sent: Friday, December 11, 2009 12:28 AM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] JIT on Windows CE Hi all; I wonder if anyone is working on JIT support for Windows CE. I know the platform has lots of limitations but still I guess someone might be interested on running JIT. Regards, i.d. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to run mozilla test cases one by one using JSC
I had to do this same thing as I didn't have perl on our platform. I found modifying the perl script to output just the commands instead of actually running them was helpful. I could then just grab this output and run it wherever. Regards, Jason. -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Oliver Hunt Sent: Tuesday, November 17, 2009 3:47 PM To: ll Jefferry Cc: WebKit Development Subject: Re: [webkit-dev] how to run mozilla test cases one by one using JSC You should simply copy the entire command line you see in the run-javascriptcore-tests output, eg. /path/to/jsc -s -f ./ecma/shell.js -f ./ecma/Date/15.9.5.17.js --Oliver On Nov 6, 2009, at 12:14 AM, ll Jefferry wrote: Hi, I bring up webkit with jit on my stb box. I want to test the jit if it is fine. When i run the mozilla test cases, i found that it need the perl tools. But my platform has not the perl environment, my question is that: can i run the test cases one by one under shell environment? such us ./jsc -f .js and can you tell me how to do this? when i run ./jsc -f ./emac/array/15-4.1.js, it always exit with code 3. That means it get error. BR, Jeff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Frameloader parsing isn't cancelling for our port.
As part of our port I'm occasionally hitting the following assert in
FrameLoad::addData; but do not have a reproducible case yet. I think this is
most likely happening for failures from the network stack occurring and then a
new request being issued (I'm using ResourceHandleWin in our build).
ASSERT(m_frame-document()-parsing());
This is happening during cancel(ling) any pending loading phase during a new
request. Is there something that I need to add to the client to cancel any
outstanding requests? I'm just using the my own version of the winlauncher
code to make the requests which doesn't have any logic for cancelling existing
ones.
The stack trace during this assert shows that it's from a check to stop loading
previous requests and somehow I get into a state that the FrameLoader believes
it is still parsing data and triggers the assert during the cancel operation.
How does the FrameLoader parsing state normally reset?
stack trace ---
WEBKIT!WebCore::FrameLoader::addData(const char * 0x, int 0) line 1439
+ 72 bytes WEBKIT!WebFrameLoaderClient::receivedData(const char * 0x,
int 9082496, const WebCore::String {...}) line 484
WEBKIT!WebFrameLoaderClient::committedLoad(WebCore::DocumentLoader *
0x008a6f20, const char * 0x, int 0) line 455
WEBKIT!WebFrameLoaderClient::finishedLoading(WebCore::DocumentLoader *
0x008a6f20) line 493
WEBKIT!WebCore::FrameLoader::finishedLoadingDocument(WebCore::DocumentLoader *
0xab5f) line 2735
WEBKIT!WebCore::DocumentLoader::finishedLoading() line 330
WEBKIT!WebCore::FrameLoader::finishedLoading() line 2675
WEBKIT!WebCore::MainResourceLoader::didFinishLoading() line 394
WEBKIT!WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle *
0x008ac460) line 408
WEBKIT!WebCore::ResourceHandle::finish() line 466
WEBKIT!WebCore::ResourceHandle::cancel(const WebCore::ResourceHandleClient *
0x) line 1063 WEBKIT!WebCore::ResourceLoader::didCancel(const
WebCore::ResourceError {...}) line 334
WEBKIT!WebCore::MainResourceLoader::didCancel(const WebCore::ResourceError
{...}) line 103 WEBKIT!WebCore::ResourceLoader::cancel(const
WebCore::ResourceError {...}) line 354 + 56 bytes
WEBKIT!WebCore::ResourceLoader::cancel() line 344 + 52 bytes
WEBKIT!WebCore::DocumentLoader::stopLoading(WebCore::DatabasePolicy
DatabasePolicyContinue) line 294 + 24 bytes
WEBKIT!WebCore::FrameLoader::stopAllLoaders(WebCore::DatabasePolicy
DatabasePolicyStop) line 2234
WEBKIT!WebCore::FrameLoader::continueLoadAfterNavigationPolicy(const
WebCore::ResourceRequest {...}, WTF::PassRefPtrWebCore::FormState *
0x43c0d244, bool true) line 3428
WEBKIT!WebCore::FrameLoader::callContinueLoadAfterNavigationPolicy(void *
0x004b1a50, const WebCore::ResourceRequest {...},
WTF::PassRefPtrWebCore::FormState * 0x0011e3a4, bool true) line 3382
WEBKIT!WebCore::PolicyCallback::call(bool true) line 102
WEBKIT!WebCore::PolicyChecker::continueAfterNavigationPolicy(WebCore::PolicyAction
9463168) line 161
WEBKIT!WebFrame::receivedPolicyDecision(WebCore::PolicyAction PolicyUse) line
1535
WEBKIT!WebFramePolicyListener::receivedPolicyDecision(WebCore::PolicyAction
PolicyUse) line 129
WEBKIT!WebFramePolicyListener::use() line 100
WEBKIT!DefaultPolicyDelegate::decidePolicyForNavigationAction(IWebView *
0x0005, IPropertyBag * 0x0093, IWebURLRequest * 0x00908c20, IWebFrame *
0x0005, IWebPolicyDecisionListener * 0x) line 120 + 28 bytes
WEBKIT!WebFrame::dispatchDecidePolicyForNavigationAction(void
(WebCore::PolicyAction)* 0x00908c20, const WebCore::NavigationAction {...},
const WebCore::ResourceRequest {...}, WTF::PassRefPtrWebCore::FormState *
0x0089c7a0) line 1584 + 168 bytes
WEBKIT!WebCore::PolicyChecker::checkNavigationPolicy(const
WebCore::ResourceRequest {...}, WebCore::DocumentLoader * 0x0011e7df,
WTF::PassRefPtrWebCore::FormState * 0x0004, void (void *, const
WebCore::ResourceRequest , WTF::PassRefPtrWebCore::FormState, bool)*
0x0007, void * 0x0007) line 89
WEBKIT!WebCore::FrameLoader::loadWithDocumentLoader(WebCore::DocumentLoader *
0x004b1a50, WebCore::FrameLoadType 5128704, WTF::PassRefPtrWebCore::FormState
* 0x009076a8) line 2018
WEBKIT!WebCore::FrameLoader::load(WebCore::DocumentLoader * 0x00907460) line
1971 WEBKIT!WebCore::FrameLoader::load(const WebCore::ResourceRequest {...},
const WebCore::SubstituteData {...}, bool true) line 1912
WEBKIT!WebCore::FrameLoader::load(const WebCore::ResourceRequest {...}, bool
false) line 1898 + 40 bytes WEBKIT!WebFrame::loadRequest(IWebURLRequest *
0x009062c0) line 504
LAUNCHER!loadURL(wchar_t * 0x00906288) line 491 + 32 bytes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JIT for arm is dependant on gcc
The Microsoft ARM toolchain does not support inline assembler so I'm unable to compile any inline assembler. I'm trying to understand how to make these functions external but it doesn't appear to be straightforward (e.g. The first problem I hit was that the asm push instruction is unknown, also svc must be renamed swi and probably others. Also, I'm not able to easily create the pre/post stack frame for cacheflush as I haven't used 3 parameter assembler language before although I'm sure I could do this with a couple of hours research. Can you maybe show me how to get the jit to generate this for this toolchain? Jason. -Original Message- From: Zoltan Herczeg [mailto:zherc...@inf.u-szeged.hu] Sent: Wednesday, October 21, 2009 9:45 AM To: Jason Rukman Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] JIT for arm is dependant on gcc Hi, these entry/leave functions are implemented in assembly for all ports. It is faster this way. (Previously, the jit generated these functions, but the reviewers convinced us to do this way). External .asm files would be a nightmare, since we have to create (and maintain) the build rules for all ports. Is is difficult to implement these functions for your assembler? They are simple code fragments. Zoltan I've noticed that there are three functions that use inline gcc assembler for compiling JIT for ARM_TRADITIONAL. Is it possible for these to be reworked using the macro assembler so that JIT can be compiled without the gcc toolchain dependency for arm? (sp. I am using armasm from Microsoft?). Alternatively, perhaps this could be moved to an external .asm or .s file. This looks like it has been done for PaintHooks.asm; so maybe something similar to that. These are the functions that I am missing trying to build JIT: CacheFlush, ctiTrampoline, ctiVMThrowTrampoline ctiOpThrowNotCaught If there is a way to compile JIT without these dependencies please let me know. Thanks, Jason. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Regarding WebKit Support Libraries
George, I was wondering if you are intending to push this implementation into the current webkit respository at some point. It looks like the code in your repository is out of sync with the current tree. If anyone else has had success working with wininet on windows we'd like to know so we can also use it to enable file caching and HTTPS support. I haven't seen how we can do file caching with curl. Thanks, Jason. BSquare http://www.bsquare.com Daniel Zucker wrote: Hi Alp and Brent, My vote is to use Wininet. Hi Daniel, You can register your vote by writing and offering to maintain a WinINet http backend. We have already done one. You can find the source for it in our source drop for WinMobile. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
