16GB+ for IndexedDB In Chrome under editor.construct.net ?

thanks for sharing! i think i talked about something similar a couple of weeks ago, a user on forum was having some mobile problems with memory full, and i kept saying might be the caching storage, not the ram or vram, as those he mentioned has plenty off.

but i didn't knew about this indexdb i was just suggesting clearing the data in the history/clear cached data (images and other stuff)

yea it doesn't seem to be actual local storage as it doesn't get cleared when clearing cache in settings (which normally clears local storage). I looked into it a little apparently it is for use by web apps for more robust storage of larger files but yea much tech stuff above my pay grade...

yea it doesn't seem to be actual local storage as it doesn't get cleared when clearing cache in settings (which normally clears local storage). I looked into it a little apparently it is for use by web apps for more robust storage of larger files but yea much tech stuff above my pay grade...

have you tried the browser audit performance option? found in f12 chrome or developer tools audit... i just swapped on desktop and applied cpu + memory throttle i wonder if that helps... i don't have a 1000 event sheet template to run it atm.

are we in the right thread? im at work at the moment on a work machine, cant do any recording or anything like that and the construct website is the only one that is not blocked (they haven't figured out it is game related yet I suppose) will try the 1000+ event sheet tonight on the MSPro4, and do a dev tools performance record. the performance recording usually hits the MSpro4 quite hard but if it runs on that thing (while doing a performance record) then it should run well on pretty much anything. will try to post back tonight if not on the weekend.

Sorry just got what you were saying! . Throttle using performance audit. Not the sharpest tool in the box me.

Let me go home now, play daddy for a few hours, then check the surface pro. it maybe a graphix capability thing and the surface will show that for sure.

Construct stores several types of data locally, mostly in indexeddb ( which for the uninitiated is persistent database managed by the browser that is saved locally on the computer/tablet/phone ).

1. Itself: Construct caches the files to run itself locally so that it can run offline, which typically doesn't take up that much space. I believe we cache the last 5 versions that you have visited, but Ash will have to confirm that
2. Demo projects: the projects that you can view on the start page are downloaded and stored in indexeddb as required.
3. Browser saves: when you save to "the browser" it goes in indexeddb
4. Recent exports: recent exports are viewable in the export manager and are saved in local storage, up to 10 exports are held and the oldest is deleted if you have more
5. NWJS files: when doing NWJS exports the files required to build that version are downloaded and stored in indexeddb. These are quite large, so it makes sense to store them locally instead of downloading them each time.
6. Layout: in construct layout customisation is split into 2 parts: overall and project. The overall layout ( sizes of bars and positions ) is stored in local storage, project is stored in the project file itself.
7. Recent projects: a list of recent projects and where they are saved is stored locally, so we can show you the recent project menu

Just to reiterate all this data is stored locally on your computer so we have no access to it. Most of the large things on the list (NWJS files, recent exports, Browsers saves) have menus you can view them, how much space they are using and have options to delete individual items. Hopefully this will help you narrow down what is using all that space. You can also clear the layout customisation in the settings menu, but that is unlikely to regain you any space.

We don't directly move objects to the disk as any sort of optimisation, but we make heavy use of "Blob" objects. Blobs are similar to files, but just loose ( not in folders or any kind of filesystem ). Due to the way they are designed the contents of the blob don't have to be in RAM, so some browsers may transfer blobs (temporarily) that aren't being actively used to the disk to reduce memory pressure. We don't have any control over this process, but I imagine it's unlikely to cause any storage issues. It also won't be included in the storage quota for a domain, or be deleted when you use "clear site data".

Nepeo don't backups to the "Browser" location also go in IndexedDB? The only thing I can think of that would get clogged up with gigabytes of local storage is if there are endless local backups that aren't being cleaned up. Additionally I've no idea where the OK dialog with the "serialized value too large" error message could come from - it looks like a dialog that simply displays the contents of an error as its message, which we should avoid (it makes no sense to the user and can't be translated). In fact if people are saying it appears randomly, maybe that's the backup timer kicking off at periodic intervals...

When you are creating/opening a totally new project of 180mb 88 times in a row will fill your memory does not sounds surprising. Cause that is basically what you are doing.

Yea but no but….

1) General users are not aware of indexeddb

2) Indexeddb also gets filled up with exports and other stuff

3) It does not get deleted when deleting cache under advanced settings (which is as far as most users would venture and where most users assume all app data is stored)

4) It can only be deleted under dev tools or reduced/deleted through features of the app that created it.

5) It appears to have a max capacity of 16GB (I don’t know if this can be changed)

6) There is no warning when it is full or near to full.

7) When it is full it starts to cause storage issues with the app (and perhaps other areas of chrome) and gives cryptic messages with no indication of the issue.

Yes maybe I just happened on it early due to the way I manage project saves but all regular Construct 3 users will likely come across this issue at some stage.