729026 - google maps webgl broken: "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIDOMHTMLCanvasElement.width]

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Mathieu Pellerin]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0a1) Gecko/20120220 Firefox/13.0a1
Build ID: 20120220163053

Steps to reproduce:

Visit http://maps.google.com/ and activate the experimental mapsgl.


Actual results:

The map fails to renders. The web console displays this error:

[15:27:00.641] uncaught exception: [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIDOMHTMLCanvasElement.width]"  nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)"  location: "JS frame :: http://maps.gstatic.com/cat_js/intl/en_ALL/mapfiles/396c/maps2/%7Bmain,mod_util,mod_act,mod_act_s,mod_actbr,mod_appiw,mod_mg,mod_mssvt,mod_rating_widget,mod_strr,mod_vt%7D.js :: <TOP_LEVEL> :: line 844"  data: no]

This is a new issue which appeared in the last few days. I can remember using mapsgl less than two weeks ago without a problem.

Comment 1

[Alice0775 White]

Not a recent regression.
I can reproduce on  Firefox10.0.2, Firefox111 beta, Aurora12.0a2 and Nightly13.0a1.
And I can reproduce on  Firefox4.0.1(w/ UA spoofing)as well.

Steps to reproduce:

Visit http://maps.google.com/ and activate the experimental mapsgl.
Move zooming slider upward slowly or zoom in by wheel.

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

The problem appears to be Windows-specific:  I can't reproduce on Linux.

Comment 3

[Alice0775 White]

There are no regression window.

Cannot enable MapsGL:
http://hg.mozilla.org/mozilla-central/rev/b758d7b3e139
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110301 Firefox/4.0b13pre ID:20110301140506

Can enable MapsGL, however the error occurs:
Error: Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIDOMHTMLCanvasElement.width]
Source file: http://maps.gstatic.com/cat_js/intl/en_ALL/mapfiles/396c/maps2/%7Bmain,mod_util,mod_vt%7D.js
Line: 844
http://hg.mozilla.org/mozilla-central/rev/c0b114d35e7b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110301 Firefox/4.0b13pre ID:20110301142845

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b758d7b3e139&tochange=c0b114d35e7b

Preferences(UA spoof):
user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2");

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

Google MapsGL definitely used to work on all platforms with Firefox 8 and 9, when these were the current Firefox version. Your finding shows that it got updated and now doesn't work, even with them. CC'ing aleicht at Google. What changed in MapsGL recently, that could cause these out-of-memory errors when accessing the |width| attribute of the canvas? Note that setting |width| causes the canvas to be resized, so it makes a lot of sense that one would get a OOM error there, if |width| is too large.

Alice, when the exception occurs on MapsGL, can you please: go to the Web Console, and in the text field in the middle of the window, enter:

  document.getElementsByTagName("canvas")[0].width

and also:

  document.getElementsByTagName("canvas")[0].height

so we can see if some absurdly large size is involved.

Comment 5

[Alice0775 White]

Attachment: screen shot

(In reply to Benoit Jacob [:bjacob] from comment #4)
> Alice, when the exception occurs on MapsGL, can you please: go to the Web
> Console, and in the text field in the middle of the window, enter:
> 
>   document.getElementsByTagName("canvas")[0].width
> 
> and also:
> 
>   document.getElementsByTagName("canvas")[0].height

666 and 565.

Comment 6

[Amanda]

Thanks for passing along this report. We also noticed this on Friday, and are going to spend some time investigating today. Will let you know what we find. 

Alice, are you still able to reproduce on FF9 as well? We had only found the issue on FF10 so far. 

--Amanda

Comment 7

[Alice0775 White]

(In reply to Amanda from comment #6)
> Thanks for passing along this report. We also noticed this on Friday, and
> are going to spend some time investigating today. Will let you know what we
> find. 
> 
> Alice, are you still able to reproduce on FF9 as well? We had only found the
> issue on FF10 so far. 
> 
> --Amanda
Yes, I can reproduce on FF9.

Comment 8

[Amanda]

Thanks - we're having some issues reproducing over here. What graphics cards are in the machines you're seeing this on?

Comment 9

[Bill Baxter]

Apparently on some Windows platforms Firefox doesn't like us setting a canvas width of 8193.  It's a convenient number because it prevents browsers from trying to do GPU acceleration of the canvas, which turns out to be slow if you do a little drawing but a lot of readback.

To repro, just do this in a console:
  c = document.createElement('canvas')
  cc = c.getContext('2d')
  c.height = 1;
  c.width = 8193;

Comment 10

[Bill Baxter]

It seems to not give a memory error if you reverse the order of lines:

  c = document.createElement('canvas')
  c.height = 1;
  c.width = 8193;
  cc = c.getContext('2d') // <-- get after setting width is OK

We've been using this wide canvas since October of last year.  So probably what has changed is that for some reason our code used to get the context('2d') after setting the size, and now it's doing it before.

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

CC'ing people who know about Canvas 2D.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Almost certainly this OUT_OF_MEMORY comes from nsCanvasRenderingContext2DAzure.cpp:1333

  return mValid ? NS_OK : NS_ERROR_OUT_OF_MEMORY;

at the end of nsCanvasRenderingContext2DAzure::InitializeWithTarget.

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

The bug appears to be Windows-specific: on Linux, even using Azure, the bug can't be reproduced and the test in comment 9 doesn't reproduce either.

Comment 14

[Bas Schouten (:bas.schouten)]

So, the bug here is likely caused by the fact that we decide to create an accelerated context or not at the time of context creation, and we probably can't switch after, this is why the order change works around the issue.

The reason we don't support the switching is partially I believe, because it can create odd performance behavior in dynamically sized canvases.

Also the trick you're pulling is probably going to stop working soon on a lot of machines, as supporting 16Kx16K canvas acceleration is not far for us. I personally think it would be better to add a hint to canvases that allows telling the browser you want to do readback a lot for example.

Comment 15

[Bill Baxter]

I rolled back before the October change and the error doesn't happen, just after the October change it does happen.  So it seems the hypothesis that something changed in our code with the order of setting width and getting the context is incorrect.

Has anything changed in the Firefox GPU blacklist or whitelist this month that could explain the sudden manifestation of the error?

We can work around it, but it would be nice to know why we didn't see it sooner.

Comment 16

[Bill Baxter]

(In reply to Bas Schouten (:bas) from comment #14)
> So, the bug here is likely caused by the fact that we decide to create an
> accelerated context or not at the time of context creation, and we probably
> can't switch after, this is why the order change works around the issue.
> 
> The reason we don't support the switching is partially I believe, because it
> can create odd performance behavior in dynamically sized canvases.
> 
> Also the trick you're pulling is probably going to stop working soon on a
> lot of machines, as supporting 16Kx16K canvas acceleration is not far for
> us. I personally think it would be better to add a hint to canvases that
> allows telling the browser you want to do readback a lot for example.

It already avoids doing the trick if the max texture size is > 8192.

We'd definitely like to have a fast readback hint, but it doesn't exist yet, so we had to come up with something in the interim.

Comment 17

[Bill Baxter]

(In reply to Bill Baxter from comment #16)
> (In reply to Bas Schouten (:bas) from comment #14)
> > Also the trick you're pulling is probably going to stop working soon on a
> > lot of machines, as supporting 16Kx16K canvas acceleration is not far for
> > us.

Oh, if you mean you'll be supporting it via tiling or some similar software solution, then you're right, the trick will stop working.

Comment 18

[Mathieu Pellerin]

Is there anything being done to fix this bug (either google maps team reverting code change, and/or firefox team dealing with bug revealed by code change)? : )

Comment 19

[Bas Schouten (:bas.schouten)]

(In reply to Bill Baxter from comment #17)
> (In reply to Bill Baxter from comment #16)
> > (In reply to Bas Schouten (:bas) from comment #14)
> > > Also the trick you're pulling is probably going to stop working soon on a
> > > lot of machines, as supporting 16Kx16K canvas acceleration is not far for
> > > us.
> 
> Oh, if you mean you'll be supporting it via tiling or some similar software
> solution, then you're right, the trick will stop working.

No, D3D11 hardware supports 16Kx16K surfaces, since we'll likely be moving from D3D10 to D3D11 at some point in the near future. The limit for acceleration will just 'automagically' change for D3D11 hardware.

As far as I know there weren't significant changes in blacklisting, however there were some changes to related code, creating a larger canvas -before- getting the context should still work though, and give you a software canvas at this point.

Comment 20

[Bill Baxter]

(In reply to Bas Schouten (:bas) from comment #19)
> As far as I know there weren't significant changes in blacklisting, however
> there were some changes to related code, creating a larger canvas -before-
> getting the context should still work though, and give you a software canvas
> at this point.

That's the quick fix I went for that should go out sometime this week.

Comment 21

[Bas Schouten (:bas.schouten)]

(In reply to Bill Baxter from comment #20)
> (In reply to Bas Schouten (:bas) from comment #19)
> > As far as I know there weren't significant changes in blacklisting, however
> > there were some changes to related code, creating a larger canvas -before-
> > getting the context should still work though, and give you a software canvas
> > at this point.
> 
> That's the quick fix I went for that should go out sometime this week.

Excellent, we'll work on a more 'permanent' solution, software Azure support will provide one for sure. But we'll have to see if there's something we can do in the meanwhile.