Closed Bug 277653 Opened 15 years ago Closed 15 years ago

Random jumping around of images in dhtml game


(Core :: Web Painting, defect, P1)






(Reporter: martijn.martijn, Assigned: bzbarsky)




(Keywords: regression, testcase)


(2 files)

When playing that game the images sometimes appear in the wrong place. It looks
like they're sometimes jumping around. Older Mozilla versions don't do this, so
it's a bug. this bug occurs with a lot more games on that site, by the way.

I can't see this bug with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040809
Firefox/0.9.1+ 6:48am
But I can see the bug with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040810
Firefox/0.9.1+ 6:49am

I'll attach a testcase.
I don't see this bug occuring on my winxp machine.
Attached image image for testcase
Attached file Testcase
Click on the addtimer() button to start the animation.
I can see the bug occuring even with one timer, but it is much easier
noticeable when you have pushed the button 3 or 4 times.
I've made a screen recording, in case you don't see the bug:
Hmm, now with just one click I can easily see the bug.
I think this could be a regression from bug 230170, by the way, looking at the
checkins of that period.
Correction from comment 0: I can also see this bug on my winxp machine.
Probably worth mentioning that these games use image clipping to move between 
animation frames in the gifs. 

The script clips to the correct part of the gif, and then immediately shifts 
the x,y pos of the gif to the correct position to show an animated image.

It looks like Moz is updating the image immediately after the clip, and then 
re-updating after the x,y pos are updated.

The original regression is almost certainly due to some sort of interaction
between bug 230170 and painting, yes.

In a current build I can get this testcase to behave if I not only remove the
bug 230170 patch (do immediate processing of the restyle event), but wrap each
such processing in a view update batch.  This last is odd; I don't really see
why it would be needed.

Interestingly, if I flush out layout after setting the style then the problem
also disappears (though the animation gets slower, of course).

Taking.  I'm going to see what I can find here.
Assignee: nobody → bzbarsky
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta
Some more experimentation leaves me _very_ confused.

I tried expanding on my patch to bug 244366 by flushing reflows right before
painting too.  That fixed the testcase in this bug.  It did NOT fix the game at
<>.  In fact, when playing
that game there are no reflows to flush when we get an NS_PAINT event...

The game _is_ fixed by doing style changes individually, each in a view update
batch.  But we really don't want to do this...
Component: Layout → Layout: View Rendering
Depends on: 244366
Blocks: 234233
Ok, I found a bug in my attempt to patch bug 244366.  With that bug fixed, the
jumping disappears on both the testcase and the game.

The patch still has issues, of course, but at least it's the right general idea.
Fixed by patch in bug 244366.
Closed: 15 years ago
Resolution: --- → FIXED
Blocks: 230170
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.