Open Bug 596707 Opened 9 years ago Updated 9 years ago
Sand Trap - sand particles painted on screen larger than in chrome
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
OS: Windows 7 → Windows XP
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [chromeexperiments] → [painting-perf][chromeexperiments]
Version: unspecified → Trunk
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?
blocking2.0: --- → ?
(In reply to comment #2) > Hmm. I think we have a separate bug on the performance issues here Filed bug 596746.
(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.
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.
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!
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.
Boris, if you find this isn't a JS bug, please send it back to us!
Assignee: nobody → general
QA Contact: thebes → general
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. ;)
Assignee: general → nobody
QA Contact: general → thebes
I don't think this blocks.
blocking2.0: ? → -
Well, except insofar as this is a graphics performance regression on Windows as far as I can see, right?
Though Chris... could you check what things look like if you disable d2d/d3d?
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).
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!
You need to log in before you can comment on or make changes to this bug.