[Webkit-unassigned] [Bug 34372] [GTK] Position queries are lagging

[bugzilla-daemon at webkit.org]

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


Benjamin Otte <otte at gnome.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |otte at gnome.org




--- Comment #16 from Benjamin Otte <otte at gnome.org>  2010-03-15 08:51:25 PST ---
I think we should come up with an order of priorities and then apply these
priorities to all the idles and timeouts properly. (People here seem to just
swap g_timeout_add() with g_idle_add() randomly and hope stuff works.)

http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00184.html has a
longer elaboration about that topic and how I solved it in Swfdec. (The Swfdec
solution is ok, but far from perfect.)
I'd also be interested in how other browsers prioritize events.

There's a bunch of possible event sources and all of them can take nontrivial
amount of time and starve a CPU:
1) user events (can trigger lots of JS that toggles a lot of the document)
2) JS timeouts (can trigger JS, and we all know what that means)
3) reads from data (can trigger extensive relayouting)
4) the media engine (can trigger expensive repaints)
5) repaint events (shadows!)
Repaints can be triggered by the first 4 as well as the window system.

The most important goal you want to achieve IMO is that user input is handled
before anything else. This includes actually handling the event in gtk and the
browser (GDK_PRIORITY_EVENTS) and repainting the parts of the screen that need
a repaint due to the user input (GDK_PRIORITY_REDRAW). Those are defined in
http://git.gnome.org/browse/gtk+/tree/gdk/gdkevents.h#n43 and then you gotta
stuf the rest of the events in there to guarantee that this happens but that
repaints do not starve important stuff.

No idea how to best achieve this though. Would need to think more about this
code to have a clear opinion.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.