Re: [webkit-dev] Enable REQUEST_ANIMATION_FRAME on all ports? (was Re: ENABLE flag cleanup strawman proposal)

[James Robinson]

On Sun, Sep 25, 2011 at 6:52 PM, Darin Adler  wrote:

> On Sep 25, 2011, at 12:20 AM, James Robinson wrote:
>
> > The TIMER based support for RAF is very new (only a few weeks old) and
> still has several major bugs. I'd suggest letting it bake for a bit before
> considering turning it on for all ports.
>
> Got it.
>
> > Fundamentally I don't think this feature can be implemented reasonably
> well with just timers, so port maintainers should take a really careful look
> at the level of support they want to have for this feature when deciding if
> they want to support it.
>
> This may contradict the recommendation above. If the timer-based version is
> too low quality then maybe we shouldn’t put ports in the position of
> shipping with a substandard implementation rather than simply having the
> feature omitted.
>

Perhaps if I expand on my concerns a bit it'll be clearer what the right
option is.

The goal of requestAnimationFrame is to allow web authors to have
high-quality script-driven animations.  To use a concrete example, when
playing angry birds (http://chrome.angrybirds.com/) and flinging a bird
across the terrain, the RAF-based animation should move the bird at a
uniform rate across the screen at the same framerate as the physical display
without hitches or interruptions.  An additional goal is that we shouldn't
do any unnecessary work for frames that do not show up on screen, although
it's generally necessary to do this in order to satisfy the first goal as
I'll show below.  There are two main things that you need in order to
achieve this that are difficult or impossible to do with a WebCore Timer: a
reliable display-rate aligned time source, and a source of feedback from the
underlying display mechanism.

The first is easiest to think about with an example.  When the angry bird
mentioned above is flying across the screen, the user should experience the
bird advancing by the same amount every time their display's update
refreshes.  Let's assume a 60Hz display and a 15ms timer (as the
current REQUEST_ANIMATION_FRAME_TIMER code uses), and furthermore assume
(somewhat optimistically) that every frame takes 0ms to process in
javascript and 0ms to display.  The screen will update at the following
times (in milliseconds): 0, 16 2/3, 33 1/3, 50, 66 2/3, 83 1/3, 100, etc.
 The visual X position of the bird on the display is directly proportional
to the time elapsed when the rAF handler runs, since it's interpolating the
bird's position, and the rAF handler will run at times 0, 15, 30, 45, 60,
etc.  We can thus determine the visual X position of the bird for each
frame:

Frame 0, time 0ms, position: 0, delta from last frame:
Frame 1, time 16 2/3ms, position: 15, delta from last frame: 15
Frame 2, time 33 1/3ms, position: 30, delta from last frame: 15
Frame 3, time 50 0/3 ms, position: 45, delta from last frame: 15
Frame 4, time 66 2/3 ms, position: 60, delta from last frame: 15
Frame 5, time 83 1/3 ms, position: 75, delta from last frame: 15
Frame 6, time 100 0/0 ms, position: 90, delta from last frame: 15
Frame 7, time 116 2/3ms, position: 105, delta from last frame: 15
Frame 8, time 133 1/3ms, position: 120, delta from last frame: 15
Frame 9, time 150 0/3 ms, position: 150, delta from last frame: 30 (!)
Frame 10, time 166 2/3 ms, position: 165, delta from last frame: 15
Frame 11, time 183 1/3 ms, position: 180, delta from last frame: 15
Frame 12, time 200 0/0 ms, position: 195, delta from last frame: 15

What happened at frame 9?  Instead of advancing by 15 milliseconds worth,
the bird jumped forward by twice the normal amount.  Why?  We ran the rAF
callback twice between frames 8 and 9 - once at 135ms and once at 150ms.
 What's actually going on here is we're accumulating a small amount of drift
on every frame (1.6... milliseconds, to be precision) between when the
display is refreshing and when the callbacks are being invoked.  This has to
catch up sometime so we end up with a beat pattern every (16 2/3) / abs(16
2/3 - 15) = 10 frames.  The same thing happens with a perfect 16ms timer
every 25 frames, or with a perfect 17ms timer every 50 frames.  Even a very
close timer will produce these regular beat patterns and as it turns out the
human eye is incredibly good at picking out and getting annoyed by these
effects in an otherwise smooth animation.

For this reason, you really need a precise time source that is tied in to
the actual display's refresh rate.  Not all displays are exactly 60Hz - at
smaller form factors 50 or even 55hz displays are not completely unheard of.
 Additionally the normal clock APIs aren't always precise enough to stay in
sync with the actual display - particularly on windows it's really hard to
find a clock that doesn't drift around all over the place.

The above analysis assumes that all calls are infinitely fast and there's no
real contention for system resources.  In practice, though, this is rarely
the case.  It's not uncommon that the system will temporarily get overlo

Re: [webkit-dev] pthreads and other threading primitives

[Geoffrey Garen]

> Do we want to require that platforms support pthreads, so that code that 
> isn't performance critical could have just one implementation?

It might work to require either POSIX threads or Win32 threads in all build 
configurations, and refactor or remove other threading code.

It's a bit weird to require POSIX threads on Windows, since, as Jarred points 
out, the implementation isn't really maintained. 

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] pthreads and other threading primitives

[paroga]

On Mon, 26 Sep 2011 14:08:41 -0400, Jarred Nicholls wrote:

Do we want to require that platforms support pthreads, so that code
that isn't performance critical could have just one implementation?


That's the status quo :)  MachineStackMarker only works with
pthreads, so QtWin32 and Win ports need pthreads-win32 right now.
 pthreads is the least common denominator at the moment.  Though
there are performance reasons for getting away from that, there is
also the fact that pthreads-win32 is an unmaintained project whose
last update was 5 years ago.


Since this thread started with bug 54836, I want to add that this is 
the main reason for the red WinCE buildbot. There is no "official" 
working pthread library for WinCE (at least for ARM) and it's not an 
easy task to get it working. So I prefer at least POSIX and Win32 API 
for threading stuff.


- Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] pthreads and other threading primitives

[Darin Fisher]

On Mon, Sep 26, 2011 at 10:47 AM, Alexey Proskuryakov  wrote:

>
> In the wake of Geoff's work to simplify threading ifdefs, and Adam's review
> of supported ports, I'm curious what people think about maintaining many
> platform branches in our WTF and JavaScriptCore threading code.
>
> Right now, it feels rather non-systemic, with some code built upon
> pthreads, Qt or Gtk libraries, and some calling into Win32 API directly.
> Some specific examples:
> - JavaScriptCore/heap/MachineStackMarker.h only works with pthreads;
> - FastMalloc works with pthreads or Win32 API;
> - ThreadSpecific uses pthreads, Qt, Gtk, or Win32 API;
> - code in various ThreadingXXX.cpp and MainThreadXXX.cpp files is entirely
> custom. Chromium doesn't even use supposedly cross-platform parts in
> MainThread.cpp.
>

This was done to avoid the queue that callOnMainThread creates.  It causes
both subtle bugs and performance problems for Chromium.  Our native
MessageLoop can implement MainThread.h directly and without those issues, so
it makes sense for us to just use our port's primitives.

However, I realize this approach was not free of trouble.  Recently, someone
added cancelCallOnMainThread, which cannot be implemented easily on top of
the Chromium MessageLoop.  Fortunately, that method is not called by any
code that the Chromium port compiles, but unfortunately, it is a bit of a
ticking-timebomb.  Someone will invariably try to use it and then be
frustrated that Chromium doesn't support it.  I think that it is a poor API
because it requires searching the work queue, so I would prefer to remove
cancelCallOnMainThread or redesign it so it can be implemented efficiently.

-Darin


>
> Supporting multiple implementation has a high cost, both in the work
> directly applied to that, and in having subtle behavior differences.
> Checking svn blame for ThreadingQt.cpp and ThreadingGtk.cpp for example, I
> see that most lines are last touched by people who are not directly
> affiliated with these ports.
>
> I remember that performance was given as the primary reason to not use
> pthreads everywhere. What pthreads functionality in particular needs to be
> reimplemented in WTF for performance? And are there big reasons to use
> anything except for POSIX and Win32 APIs for us? Do we want to require that
> platforms support pthreads, so that code that isn't performance critical
> could have just one implementation?
>
> - WBR, Alexey Proskuryakov
>
> ___
> 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] pthreads and other threading primitives

[Jarred Nicholls]

On Mon, Sep 26, 2011 at 1:47 PM, Alexey Proskuryakov  wrote:

>
> In the wake of Geoff's work to simplify threading ifdefs, and Adam's review
> of supported ports, I'm curious what people think about maintaining many
> platform branches in our WTF and JavaScriptCore threading code.
>
> Right now, it feels rather non-systemic, with some code built upon
> pthreads, Qt or Gtk libraries, and some calling into Win32 API directly.
> Some specific examples:
> - JavaScriptCore/heap/MachineStackMarker.h only works with pthreads;
> - FastMalloc works with pthreads or Win32 API;
> - ThreadSpecific uses pthreads, Qt, Gtk, or Win32 API;
> - code in various ThreadingXXX.cpp and MainThreadXXX.cpp files is entirely
> custom. Chromium doesn't even use supposedly cross-platform parts in
> MainThread.cpp.
>
> Supporting multiple implementation has a high cost, both in the work
> directly applied to that, and in having subtle behavior differences.
> Checking svn blame for ThreadingQt.cpp and ThreadingGtk.cpp for example, I
> see that most lines are last touched by people who are not directly
> affiliated with these ports.
>
> I remember that performance was given as the primary reason to not use
> pthreads everywhere. What pthreads functionality in particular needs to be
> reimplemented in WTF for performance? And are there big reasons to use
> anything except for POSIX and Win32 APIs for us?


IMHO, I think JSC should go right to the metal rather than be abstracted
with port specific threading classes.  In other words, it should be broken
out by platform threading libs - POSIX and Win32 - and not by port.  After a
very rudimentary scan, I saw no reason to not use straight Win32 and POSIX.
 This would arguably reduce port barrier-to-entry and maintenance, on top of
the obvious code simplicity and slight performance increase.


> Do we want to require that platforms support pthreads, so that code that
> isn't performance critical could have just one implementation?
>

That's the status quo :)  MachineStackMarker only works with pthreads, so
QtWin32 and Win ports need pthreads-win32 right now.  pthreads is the least
common denominator at the moment.  Though there are performance reasons for
getting away from that, there is also the fact that pthreads-win32 is an
unmaintained project whose last update was 5 years ago.


>
> - WBR, Alexey Proskuryakov
>

Definitely worth a full reviewer analysis and vote I think.  This is one of
the many WebKit cleanup tasks to consider.


>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 


*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] pthreads and other threading primitives

[Alexey Proskuryakov]

In the wake of Geoff's work to simplify threading ifdefs, and Adam's review of 
supported ports, I'm curious what people think about maintaining many platform 
branches in our WTF and JavaScriptCore threading code.

Right now, it feels rather non-systemic, with some code built upon pthreads, Qt 
or Gtk libraries, and some calling into Win32 API directly. Some specific 
examples:
- JavaScriptCore/heap/MachineStackMarker.h only works with pthreads;
- FastMalloc works with pthreads or Win32 API;
- ThreadSpecific uses pthreads, Qt, Gtk, or Win32 API;
- code in various ThreadingXXX.cpp and MainThreadXXX.cpp files is entirely 
custom. Chromium doesn't even use supposedly cross-platform parts in 
MainThread.cpp.

Supporting multiple implementation has a high cost, both in the work directly 
applied to that, and in having subtle behavior differences. Checking svn blame 
for ThreadingQt.cpp and ThreadingGtk.cpp for example, I see that most lines are 
last touched by people who are not directly affiliated with these ports.

I remember that performance was given as the primary reason to not use pthreads 
everywhere. What pthreads functionality in particular needs to be reimplemented 
in WTF for performance? And are there big reasons to use anything except for 
POSIX and Win32 APIs for us? Do we want to require that platforms support 
pthreads, so that code that isn't performance critical could have just one 
implementation?

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Help with a possible Webkit bug UPDATE

[malch]

This problem appears to be a duplicate of:

https://bugs.webkit.org/show_bug.cgi?id=61452

I have annotated that bug report with a few additional comments.

Thanks to David Brown for his help with this.
-- 
View this message in context: 
http://old.nabble.com/Help-with-a-possible-Webkit-bug-tp32503920p32503951.html
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Vendor Prefixing, was Re: New feature announcement - Implement HTML5 Microdata in WebKit

[Anne van Kesteren]

FWIW, Opera is planning to ship this unprefixed.

http://dev.opera.com/articles/view/microdata-and-the-microdata-dom-api/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Help with a possible Webkit bug

[Adam Roben]

This isn't the right mailing list for a question like this. 
 explains the different mailing lists.

But probably the best thing to do in a case like this is to file a bug at 
.

-Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Not able to play flash with windows webkit

[vswap 65]

Hi Adam,

I raised the bug .
It is reachable through link " https://bugs.webkit.org/show_bug.cgi?id=68789
"


Regards,
Swapna



On Fri, Sep 23, 2011 at 8:38 PM, Adam Roben  wrote:

> On Sep 23, 2011, at 9:36 AM, vswap 65 wrote:
>
> > After little more investigation I found that the issue is with the
> mimetype not with the flash plugin.
> > When the NP flash plugini.e., npswf.dll is installed, webkit is loading
> the dll and playing the flash with if the mimetype is changed to
> "application/x-shockwave-flash". This is valid mime-type for *.swf content.
> >
> > But in the testcase attached for the bugid: 21649, mimetype is
> "application/octet-stream".
> > And firefox is able to play even if the mimetype is
> "application/octet-stream".
> > So I wanted to know if this is a valid bug on webkit or its a content
> issue(invalid HTML content).
> > Can some please suggest us if we can raise a bug on webkit?
>
> It sounds worth filing a bug and mentioning the difference from Firefox. It
> would also be good to test other browsers.
>
> -Adam
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev