I believe int tx, int ty -- which we see sprinkled around the
rendering tree -- are the offset from the top left corner of the
current renderer's parent to the containing block. Is that correct?
In SVG we use IntSize containingBlockOffset in the rare places we have
to deal with this
On Aug 23, 2010, at 12:47 AM, Eric Seidel wrote:
Does anyone know why AXObjectCache is not ref counted? It has some
manual scheme which seems likely to have bugs in it.
http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp#L1742
There just seems to be a lot of code in Document
The Kernel usually reserves 1/4 (but up to 3/4 on some OSes) of the address
space for itself + you can get fragmentation. So the linker only can use
part of the 4gb of ram in your machine. So switching to a 64 bit linker
would probably fix the problem for now. Another option is to disable some
On Aug 23, 2010, at 12:51 AM, Eric Seidel wrote:
I believe int tx, int ty -- which we see sprinkled around the
rendering tree -- are the offset from the top left corner of the
current renderer's parent to the containing block. Is that correct?
In SVG we use IntSize containingBlockOffset
SVG gets such a bad wrap. :) Wouldn't breaking WebCore into smaller
libraries fix these linker problems longer-term? For example,
breaking out platform into a .a, or the JS bindings? I guess we'd
have to make them .dylib instead of .a if we wanted to actually make
the linker happier.
On Mon,
On Aug 23, 2010, at 2:38 AM, Eric Seidel wrote:
SVG gets such a bad wrap. :) Wouldn't breaking WebCore into smaller
libraries fix these linker problems longer-term? For example,
breaking out platform into a .a, or the JS bindings? I guess we'd
have to make them .dylib instead of .a if we
- it would allow the client to live in WebCore.
FWIW, Geolocation seems to take both approaches. One implementation is down
in Navigator/Document/DOMWindow,
but the mock controller is on Page. I've found the low-level approach much
easier to implement.
My understanding was that clients for
On Mon, Aug 23, 2010 at 2:26 AM, Jeremy Orlow wrote:
The Kernel usually reserves 1/4 (but up to 3/4 on some OSes) of the address
space for itself + you can get fragmentation. So the linker only can use
part of the 4gb of ram in your machine. So switching to a 64 bit linker
would
Recently there was a need to make the smart pointer wrapping GLib
reference-counted types more general. In this case it was to extend it to Cairo.
Here is the bug for that: https://bugs.webkit.org/show_bug.cgi?id=44354
It struck me that the name GRefPtr wasn't very applicable to this type any
Would this then combine with the Mac/Win port's RetainPtr in some way?
On Mon, Aug 23, 2010 at 9:49 AM, Martin Robinson mrobin...@webkit.org wrote:
Recently there was a need to make the smart pointer wrapping GLib
reference-counted types more general. In this case it was to extend it to
On Aug 23, 2010, at 4:33 AM, Maciej Stachowiak wrote:
- tx, ty are the origin of the parent's coordinate system relative to the
origin for its layer. When a layer paints, it establishes a CTM such that its
own origin is 0, 0 (I think).
They are relative to a painting root, which will
On Aug 23, 2010, at 12:11 PM, David Hyatt wrote:
(hopefully less verbose, but you get the idea). tx, ty could be named
parentOffsetFromLayerCoordinates or something. This seems to be the intent
of the names - that x,y is a point and tx, ty is a translation. But this
doesn't work in
Has anyone looked at our coverage-generating scripts in a while?
Seems to die trying to build libANGLE these days, but I believe the
scripts have been dead for much longer.
I'm interested in finding (and removing) dead code from WebCore.
There is a whole bunch more dead code now that the
Started yesterday. A bunch of layout tests crash in some ASSERT in
WebKitPluginHost / testnetscapeplugin.
// Entry points
extern C
NPError STDCALL NP_Initialize(NPNetscapeFuncs *browserFuncs)
{
#if XP_WIN
// Simulate Flash and QuickTime's behavior of crashing when
NP_Initialize is called
This is gonna kill me. Does no one else run the layout tests...?
On Mon, Aug 23, 2010 at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote:
FYI, there was a series of plugin patches committed this weekend:
http://trac.webkit.org/search?q=pluginnoquickjump=1changeset=onwiki=on
Best,
Ryosuke Niwa
Hi,
there seems to be a bug in webkit (affecting webkitgtk, qtwebit and
chromium) which leads to incorrect rendering of:
http://www.flumotion.com/first_webm_live_event.php
I can reproduce it with midori (webkitgtk), arora (qtwebkit) and
chromium, haven't tried anything else.
Looks like the
A reduction would be useful.
My general approach is: file a bug first, ask questions later. :)
Once we have a bug, we can attach a reduction and work towards
resolution (even if that means no change to WebKit).
-eric
On Mon, Aug 23, 2010 at 3:06 PM, Martin Sourada
martin.sour...@gmail.com
FYI, I was seeing this too over the weekend.
Simon
On Aug 23, 2010, at 2:54 PM, Eric Seidel wrote:
This is gonna kill me. Does no one else run the layout tests...?
On Mon, Aug 23, 2010 at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote:
FYI, there was a series of plugin patches committed
I wonder if its related to Safari 5.0.1. The bots are seeing
failures, but not nearly a many as I'm seeing. Adam Barth is also
seeing a whole bunch of plugin-related crashes.
On Mon, Aug 23, 2010 at 3:09 PM, Simon Fraser simon.fra...@apple.com wrote:
FYI, I was seeing this too over the
On Mon, 2010-08-23 at 15:09 -0700, Eric Seidel wrote:
A reduction would be useful.
My general approach is: file a bug first, ask questions later. :)
Once we have a bug, we can attach a reduction and work towards
resolution (even if that means no change to WebKit).
20 matches
Mail list logo
