596707 - Sand Trap - sand particles painted on screen larger than in chrome.

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Chris DeCairos (:cade)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.55 Safari/534.3
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100914 Firefox/4.0b7pre

While playing the Sand Trap game in both Chrome nightly and Firefox nightly builds side by side, I noticed that the sand particles in Firefox are drawn much bigger than in chrome. to clarify, one particle in Firefox is 2 or 3 times the size as in chrome.

Reproducible: Always

Comment 1

[David Humphrey (:humph)]

This runs my fans and pegs my CPU on Minefield on Mac (10.6). I see the following for a FF nightly vs. Chrome:

Minefield:
----------------------------------------------------------
27.8%	27.8%	CoreGraphics	argb32_sample_ARGB32
0.0%	27.8%	CoreGraphics	 argb32_image_mark
0.0%	27.8%	CoreGraphics	  argb32_image
0.0%	27.8%	libRIP.A.dylib	   ripl_Mark
0.0%	27.8%	libRIP.A.dylib	    ripl_BltImage
0.0%	27.8%	libRIP.A.dylib	     ripc_RenderImage
0.0%	27.8%	libRIP.A.dylib	      ripc_DrawImage
0.0%	27.8%	CoreGraphics	       CGContextDrawImage
0.0%	27.8%	XUL	        _cairo_quartz_draw_image
0.0%	27.8%	XUL	         _cairo_quartz_surface_fill
0.0%	27.8%	XUL	          _cairo_surface_fill
0.0%	27.8%	XUL	           _cairo_gstate_fill
0.0%	27.8%	XUL	            _moz_cairo_fill_preserve
0.0%	27.8%	XUL	             nsCanvasRenderingContext2D::DrawImage(nsIDOMElement*, float, float, float, float, float, float, float, float, unsigned char)
21.2%	21.2%	CoreGraphics	argb32_sample_argb32
0.0%	21.2%	CoreGraphics	 argb32_image_mark
0.0%	0.0%	CoreGraphics	 argb32_image
0.0%	0.0%	libRIP.A.dylib	  ripl_Mark
0.0%	0.0%	libRIP.A.dylib	   ripl_BltImage
0.0%	0.0%	libRIP.A.dylib	    ripc_RenderImage
0.0%	0.0%	libRIP.A.dylib	     ripc_DrawImage
0.0%	0.0%	CoreGraphics	      dle_ExecuteDisplayList
0.0%	0.0%	CoreGraphics	       dle_Execute
0.0%	0.0%	CoreGraphics	        CGDisplayListDelegateExecute	
0.0%	0.0%	libRIP.A.dylib	         ripc_TilePattern
0.0%	0.0%	libRIP.A.dylib	          ripc_GetColor
0.0%	0.0%	libRIP.A.dylib	           ripc_Render
0.0%	0.0%	libRIP.A.dylib	            ripc_DrawPath
0.0%	0.0%	CoreGraphics	             CGContextDrawPath
0.0%	0.0%	CoreGraphics	              CGContextFillPath
0.0%	0.0%	XUL	               _cairo_quartz_surface_fill
0.0%	0.0%	XUL	                _cairo_surface_fill
0.0%	0.0%	XUL	                 _cairo_gstate_fill
0.0%	0.0%	XUL	                  _moz_cairo_fill_preserve
0.0%	0.0%	XUL	                   nsCanvasRenderingContext2D::DrawPath(nsCanvasRenderingContext2D::Style, gfxRect*)


Chrome:
----------------------------------------------------------
34.0%	34.0%	CoreGraphics	sseCGSBlendXXXX8888
0.0%	34.0%	CoreGraphics	 argb32_image
0.0%	17.2%	libRIP.A.dylib	  ripd_Mark
0.0%	17.2%	libRIP.A.dylib	   ripl_BltImage
0.0%	17.2%	libRIP.A.dylib	    ripc_RenderImage
0.0%	17.2%	libRIP.A.dylib	     ripc_DrawLayer
0.0%	17.2%	CoreGraphics	      CGContextDrawLayerAtPoint
0.0%	16.8%	libRIP.A.dylib	  ripl_Mark
0.0%	16.8%	libRIP.A.dylib	   ripl_BltImage
0.0%	16.8%	libRIP.A.dylib	    ripc_RenderImage
0.0%	16.8%	libRIP.A.dylib	     ripc_DrawImage
0.0%	16.8%	CoreGraphics	      CGContextDrawImage

Comment 2

[Boris Zbarsky [:bzbarsky]]

Hmm.  I think we have a separate bug on the performance issues here, but that might be only for the Windows stuff.  David, can we get a separate bug filed on the Mac performance and focus on the behavior difference here?  I assume you're not seeing the size difference on your Mac?  I'm not on mine...

Chris, your zoom level is set to 100%, right?  Does disabling hardware acceleration make a difference in the rendering you see?

Comment 3

[David Humphrey (:humph)]

(In reply to comment #2)
> Hmm.  I think we have a separate bug on the performance issues here

Filed bug 596746.

Comment 4

[Chris DeCairos (:cade)]

(In reply to comment #2)
> Chris, your zoom level is set to 100%, right?  Does disabling hardware
> acceleration make a difference in the rendering you see?

Yes, zoom is at 100%. I tried disabling hardware accelleration, and saw no noticeable difference in the rendering.

as a side note, I noticed an option in the settings to recalculate the sand resolution, but running it causes no change as well.

Comment 5

[Derek Detweiler]

Hi all, you may have already figured this out, but I thought I'd pipe in. The large sand size is by design, but is directly related to canvas rendering performance.

When the game loads for the first time, or "Recalculate Sand Resolution" is clicked, the game runs through a few FPS tests, starting with a very large sand resolution and incrementally making the grains finer until the frame rate per second becomes too slow. I've noticed that, on the older version of Sand Trap, Firefox 3.6 routinely fails the first test, so it often uses the largest grains: that was my best idea to make the game still playable - a larger number of grains to render made it unplayable and slow. I haven't tried it in any beta releases. The latest version of Sand Trap (released yesterday, and now to which is linked above) starts at an even lower threshold with lowered canvas resolution, so it will probably make it through a few more FPS tests.

Regardless, if it helps in any way, I can supply the non-minified and non-obfuscated source code.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So what this comes down to is that the resolution calculation is slower in firefox than in chrome on Chris' machine, right?  Derek, I'd love a link to that calibration code in readable form!

Comment 7

[Derek Detweiler]

That's right. Here's the source: http://gopherwoodstudios.com/sandtrap/sand-trap-source.htm

Calculations are performed on rows 458-504. box.resolutionCalculation starts at -2; if it fails, it drops to -3, otherwise it starts climbing. As soon as it fails, it drops back a resolution and the game starts. 2+ are pure resolutions of sand per box square 2x2, 3x3, etc. Below that canvas scale and grain count are reduced: lines 713 - 742.

Comment 8

[Joe Drew (not getting mail)]

Boris, if you find this isn't a JS bug, please send it back to us!

Comment 9

[Boris Zbarsky [:bzbarsky]]

Sure thing.  Three things make me say this is a graphics issue, not a JS one:

1)  On my Mac, we go two steps further in the resolution chain than Chrome does
    (getting to the first "It's getting pretty sandy" in the source Derek
    provided, after I tweaked it to actually call the calibration code).  So I
    actually get the opposite of this bug, on Mac; we're faster than Chrome
    here.

2)  If I profile the calibration step after that message is shown (which is the
    step where we finally drop below 7fps, presumably), the numbers look
    something like this:

 33% painting to screen (almost all of this painting the canvas)
 25% fillRect on the canvas
 20% drawImage on the canvas
  2% setting canvas styles
 16% JS execution

3)  If I enable GL layers on Mac, I get some smearing, but also 3 more
    calibration steps (as many as the game will do, in fact).

So it sounds like the problems Chris is seeing are almost certainly graphics-performance related and we need someone on Windows to measure this and stop looking at all the Mac profiles in here.  ;)

Comment 10

[Joe Drew (not getting mail)]

I don't think this blocks.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Well, except insofar as this is a graphics performance regression on Windows as far as I can see, right?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Though Chris... could you check what things look like if you disable d2d/d3d?

Comment 13

[Bas Schouten (:bas.schouten)]

I tested this, the sand grains get pretty big with GDI. And with D2D it's a bit better, but not great. With D2D, D3D10 layers and Vlad's fix for DrawImage, we do really well (better than Chrome).

Comment 14

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  If D2D is better than GDI, sounds like this isn't a regression.  And good to hear that with the works we do well!

Comment 15

[Mayank Bansal]

This runs fine now.