If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

GTK2 builds skip frames in DHTML animations

RESOLVED FIXED

Status

()

Core
Widget: Gtk
--
major
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: bz, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

BUILD: GTK2 build from any time in the last month (GTK1 builds are OK)

STEPS TO REPRODUCE:
1)  Load http://www.speich.net/computer/3d.php
2)  Click the "here" link in the first paragraph in the left white box (the
    sentence reads "Click here to open a new browser window for testing")
3)  In the window that opens, click "Big cube" and don't move the mouse cursor
    until a square appears in the display area and the instructiosn talk about
    moving the mouse out of the window.
4)  Move your mouse out of the window to start the test.
5)  Watch the counter after "Testing".

EXPECTED RESULTS: Counter says 001, 002, 003, etc, up to 050.

ACTUAL RESULTS: Counter says 002, 004, 006, etc up to 050.

NOTE: This means we're dropping every other frame of the animation.

NOTE: As I said, GTK1 builds are OK.  So are Windows builds.  Mac apparently has the same issue as GTK2; I'll file a separate bug on that.

It's not a perf issue as far as I can tell (we're finishing faster than the GTK1 build)....  Not sure what the deal is, but something about how we dispatch paint events, looks like.  Given the work we did in Gecko 1.8 to fix issues like this, I'd really like to figure out what's going on here.
Flags: blocking1.9a1?
Filed bug 332933 for the Mac issue.
Depends on: 326273
Looks like bug 326273 fixes this.  ;)
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: blocking1.9a1?
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.