Closed Bug 712621 Opened 13 years ago Closed 12 years ago

Customer reports significant performance problems compared to Chrome.

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: JStagner, Unassigned)

References

(Blocks 1 open bug)

Details

I've run side by side comparisons and Chrome is faster at execution and 1st load time is 10x faster on chrome.

Here is the customer email : 
----------------------------------------------------------------------------

From: "Miguel Angel Pastor" <miguel.pastor@onan-games.com>
To: "Joe Stagner" <jstagner@mozilla.com>
Cc: cyberdees@mozilla.com
Sent: Sunday, December 18, 2011 8:46:57 AM
Subject: Re: [Apps & Technical Assistance] Miguel Pastor (Onan Games) ‹› Joe Stagner (Mozilla)


Hi Joe,

sorry for the delay, busy week xmas is coming

Our main issue with firefox is javascript performance
mandreel games run around 3x slower on firefox compared to chrome

you can check these 3 titles:
http://chrome.monsterdashgame.com/ 
http://gunbros.glu.com
https://plus.google.com/u/0/games/777131296458


for audio we have another issue, 
if you take as example GT Racing, for that game we need pitch support, engine sounds use pitch. On firefox we don't have something like web audio, you have data audio, but you need to do software mixing and the audio lag is really noticeable at least on windows, around 200 ms, because that we use flash for audio on firefox

and another issue it's the lack of FileSystem API support, application cache is ok for static content, but not so good for games and the size is not enought, for example GT Racing is a 300 megabytes game. On chrome we stream the data and save it using FileSystem API, that's something we can't do on firefox

Miguel
(In reply to JStagner@Mozilla.com from comment #0)
> for audio we have another issue, 
> if you take as example GT Racing, for that game we need pitch support,
> engine sounds use pitch. On firefox we don't have something like web audio,
> you have data audio, but you need to do software mixing and the audio lag is
> really noticeable at least on windows, around 200 ms, because that we use
> flash for audio on firefox

For this our current plan is https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html.

> and another issue it's the lack of FileSystem API support, application cache
> is ok for static content, but not so good for games and the size is not
> enought, for example GT Racing is a 300 megabytes game. On chrome we stream
> the data and save it using FileSystem API, that's something we can't do on
> firefox

Jonas can probably address this.
(In reply to JStagner@Mozilla.com from comment #0)
> http://chrome.monsterdashgame.com/ 
> http://gunbros.glu.com

Both of these abort on trunk with 
[10:46:15.429] Use of XMLHttpRequest's responseType attribute is no longer supported in the synchronous mode in window context. @ http://chrome.monsterdashgame.com/
[10:46:15.444] uncaught exception: [Exception... "A parameter or an operation is not supported by the underlying object"  code: "15" nsresult: "0x8053000f (NS_ERROR_DOM_INVALID_ACCESS_ERR)"  location: "http://chrome.monsterdashgame.com/ZombieDash/mandreel.js Line: 1"]

This is caused by bug 701787.
Depends on: 701787
Starting with Firefox 11 we support storing files in IndexedDB.

If you simply want something that is similar to a filesystem you can do:

When setting up the database:

  ...
  db.createObjectStore("files");
  ...


To read a file from the "filesystem"

  ...
  db.transaction("files").objectStore("files").get("/my/file").onsuccess = 
    function(e) {
      resultFile = e.target.result;
    };
  ...


To store a file in the "filesystem"

  ...
  db.transaction("files").objectStore("files").put(theFile, "/my/file");
  ...


In other words, files as simply one type (along with strings, numbers, booleans, dates, objects, arrays, etc) that you can store in IndexedDB. You can even store them as part of another object:

  db.createObjectStore("carTypes", { keyPath: "name" });

  ...

  db.transaction("carTypes").objectStore("carTypes")
    .put({ name: "Porsche Boxster S",
           topSpeed: 160,
           acceleration: 13,
           picture: myFile,
           price: 20000})


This way you can store files along with the other data you are storing, rather than in a separate filesystem storage.

But either solution works, and having a separate "filesystem" objectStore might be easier if you are having to use the FileSystem API in Chrome.

For what it's worth, Microsoft also supports files in indexedDB in IE10. And no other vendor than google expressed support for the File System API at TPAC.
Maybe we could get someone to write a compatibility shim to emulate the FileSystem API on top of IndexedDB?
We definitely could. Though my understanding is that the API isn't terribly user friendly due to having to be asynchronous in every step. Additionally the File system API has the ability to do writes on partial files which indexedDB doesn't yet (though it's not a feature that most people request).

Another alternative would be to write a library that spans both APIs and exposes a author-friendly API.
Blocks: gecko-games
I've written a library to use FileSystemAPI on top of IndexedDB: https://developer.mozilla.org/en-US/demos/detail/filesystemdb
The code isn't so good (as I written it mainly to learn JavaScript) and the library isn't complete, but if you want I can continue and complete the work.
I don't think we should write a shim that implements the File Systems API on top of IndexedDB, we should write a shim that implements Files in IndexedDB on top of the File Systems API.
I can't find any bug about the implementation of the FileSystem API, however I'd like to help about this (if we want to support it). I've yet some knowledge of the API as I've written that library.
FYI: I started implementing FileSystem API here:
https://github.com/LCID-Fire/jsFileSystem

Could use some help ;)
(In reply to lcid-fire from comment #9)
> FYI: I started implementing FileSystem API here:
> https://github.com/LCID-Fire/jsFileSystem
> 
> Could use some help ;)

I did an implementation here: https://developer.mozilla.org/en-US/demos/detail/filesystemdb
I'll post to Gitorious asap.
(In reply to Marco Castelluccio from comment #10)
> I did an implementation here:
> https://developer.mozilla.org/en-US/demos/detail/filesystemdb
Did you actually try to execute Chrome's Unit Tests on your implementation? From a quick look there seem to be some basic problems (e.g. properties are not readonly).
Also I think the license is a little restrictive.
(In reply to lcid-fire from comment #11)
> Did you actually try to execute Chrome's Unit Tests on your implementation?
> From a quick look there seem to be some basic problems (e.g. properties are
> not readonly).
> Also I think the license is a little restrictive.

No, I didn't. My implementation is a WIP, I did it mainly to learn JavaScript and the IndexedDB API. It isn't meant to be really used as is.
However there is something impossible to support, for example the feature that the files created through the filesystemapi are accessible by users on their local filesystems.
(In reply to Marco Castelluccio from comment #12)
> However there is something impossible to support, for example the feature
> that the files created through the filesystemapi are accessible by users on
> their local filesystems.

Where is this stated? On Chrome they are hidden, too. I don't even think this is desirable.
Do you know whether it is possible to put Blobs into the IndexedDB?
(In reply to lcid-fire from comment #13)
> Where is this stated? On Chrome they are hidden, too. I don't even think
> this is desirable.

Look at the use cases of the API (http://www.w3.org/TR/file-system-api/#use-cases).

> Do you know whether it is possible to put Blobs into the IndexedDB?

I don't know, but I don't think so. I've used FileReader to read the blobs and save their contents on the DB.

If you have other questions please send me a mail, I don't want to fill with garbage this bug.
The spec says that you should be able to store Blobs in IndexedDB, and this is possible in the IE10 and Firefox 11 implementations. See comment 3.

I definitely would *not* encourage reading the blob data in and storing directly in the database. Simply not supporting older versions seems like a better alternative.

You should be able to implement the full FileSystem API using indexedDB. The FileWriter API should be implementable using BlobBuilder.
(In reply to Jonas Sicking (:sicking) from comment #15)
> The spec says that you should be able to store Blobs in IndexedDB, and this
> is possible in the IE10 and Firefox 11 implementations. See comment 3.
> 
> I definitely would *not* encourage reading the blob data in and storing
> directly in the database. Simply not supporting older versions seems like a
> better alternative.

So I'll change this in my code, I'll save directly the blobs.

> You should be able to implement the full FileSystem API using indexedDB. The
> FileWriter API should be implementable using BlobBuilder.

This is what I did (also if my implementation isn't complete)
However there are some limitations, I think. For example with IndexedDB you can't write partially to files.
> > You should be able to implement the full FileSystem API using indexedDB. The
> > FileWriter API should be implementable using BlobBuilder.
> 
> This is what I did (also if my implementation isn't complete)
> However there are some limitations, I think. For example with IndexedDB you
> can't write partially to files.

Yeah, this will result in a (potentially big) performance difference. But you can still get the same behavior. If an entry contains a 10MB file and someone tries to write 1MB of data 5MB into the file, you can simply do:

bb = new MozBlobBuilder();
bb.append(oldBlob.slice(0, 5*1024*1024));
bb.append(newData);
bb.append(oldBlob.slize(5*1024*1024 + newData.size));
resultBlob = bb.getBlob();
writeToFilesystem(resultBlob, location);


For FF12 I'm hoping we'll have time to add support for partial file writes.
But note that it doesn't sound like the use cases in comment 0 needs partial file writes.
Product: Web Apps → Core
QA Contact: general → general
So... what is this bug about at this point?  There are at least three separate issues in comment 0, lots of discussion, but I have no idea what's involved in actually making this bug "resolved".

Did anyone ever spin off a separate bug on the "slower than Chrome" bit?  If not, should that happen?  Or should this bug be refocused on that?
We've grabbed the URLs from comment 0 an added them to the list of games we should be testing/profiling; I don't think there's anything more that we can do here.  Profiling should let us file additional bugs as needed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.