Hi,
I've been hacking on my variant of DRT. What I find is that on linux,
when I load a page with flash, it crashes.
I believe that this is related to an issue where flash 10.1 needs the
host environment to call gtk_init.
See:
https://bugs.webkit.org/show_bug.cgi?id=40567
http://trac.webkit.org/changeset/61307
for the bug and recent fix applied to the qt webkit port.
What I noticed is that we have code to call gtk_init in
TestShellPlatformDelegate and that this is called by
test_shell_main.cc. However this code is not called by
DumpRenderTree's main().
Should we be calling this code in DumpRenderTree's main() as well? The
code I'm thinking of calling is:
TestShellPlatformDelegate::PreflightArgs(&argc, &argv);
CommandLine::Init(argc, argv);
const CommandLine& parsed_command_line = *CommandLine::ForCurrentProcess();
TestShellPlatformDelegate platform(parsed_command_line);
although I realize now that chromium DumpRenderTree may not be allowed
to use this code? I don't really understand the dependencies fully.
In any case I'm curious to hear what you think we should do to address
this issue, if anything, in DumpRenderTree. I've worked around the
issue on my project by inserting the code above into main().
BTW what's the difference between DumpRenderTree and test_shell_main?
Why would someone use one or the other?
Thanks,
Bryan
Flash expects to be able to talk to an X server, and I think windowed
Flash expects to have an X window to parent on. Does DRT create an
OS-level window or does it just render into pixel buffers? In the
former case, you should be initializing GTK at startup already, while
in the latter case I don't think Flash will work.
I think it's the former case but I'll defer to someone that knows DRT
better than I do.
I can report that without a call to gtk_init at startup, the DRT
process crashes when trying to render flash. Once I add a call to
gtk_init() the crash goes away. Whether flash is doing something
meaningful or not I don't know. I can look at a dumped screenshot to
find out if the flash gets rendered.
>
On Thu, Jul 29, 2010 at 2:50 PM, Dimitri Glazkov <dgla...@google.com> wrote:
> I think it would be useful to find out which DRT are you working in.
> There are multiple implementations of DRT, one for each port --
> including Chromium.
>
> :DG<
>> --
>> Chromium Developers mailing list: chromi...@chromium.org
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/a/chromium.org/group/chromium-dev
>>
>
Can you fix that please? :)
:DG<
I don't fully understand what gtk_init() does or whether we want to
call it. I assume so, since it prevents crashes, but if it has other
undesirable side effects for DRT maybe we don't want to call it unless
plugins are being loaded.
Can someone with DRT knowledge (especially knowledge on how to build
DRT in the webkit tree) help me to make sure I'm putting together a
change that's compatible with both chromium build and webkit build? As
I understand it this code needs to build in webkit land as well.
Thanks,
Bryan
Let me know if you end up needing to support a gtkless DRT & I can
share that code with you.
Thanks,
Bryan
PS: Xvfb is definitely the bottleneck for greater layout test
parallelization on Linux (that is, when running on a fast enough
machine Xvfb goes to 100% CPU and the test_shell processes contend for
its time). But that's because test_shell draws everything it renders;
hopefully DRT wouldn't be making X calls except when doing plugin
work, though that might be tricky to implement.
I can imagine doing something like putting DRT into "needs X" mode for
the plugin tests, where it knows to do some extra work and talk to an
Xvfb for those tests. It would be similar to what we do for the HTTP
tests I think.
Another approach is to lazy-init all the X stuff in one of the first
plugin callbacks -- that is, as soon as a plugin is created, flip a
flag in DRT somewhere that makes it render via X, and then unflip the
flag as soon as the last plugin is destroyed.
Eyeballing the webkit builder cycle times at
http://build.chromium.org/buildbot/waterfall/stats
Linux ~ 7
Win ~ 13
Mac ~ 26
But in general, yep: since NPAPI is in terms of X handles, even
windowless drawing involves X server round-trips. We put some stuff
on the X server, we tell the plugin "hey go draw on the X server",
then we go fetch that stuff from the X server. Performance is not so
good. Hurry up with Pepper. ;)
Search for "targeting the pixmap" in
webkit/glue/plugins/webplugin_delegate_impl_gtk.cc .
On Mon, Aug 2, 2010 at 9:35 AM, Darin Fisher <da...@chromium.org> wrote: