Feedback

[Schmockbert]

Hey hey! Pretty nifty so far, but I do have some suggestions:

1) I think an auto-hide/show on hover or a toggle button for displaying the roller would be nice.

2) While I can easily drag the roller to a vertical layout, a toggle for horizontal/vertical scrolling would make this better, as it's hard to scroll just one line up/down.

3) A slight fade to transparency at the top/bottom (or left/right in vertical layout) edges of the roller would probably do a lot visually.

4) I can't really figure out how, if at all, the games are sorted. Basic things like alphabetically/recently played/most played would be great.

5) A memory footprint of 200 megs seems rather large, maybe there's some optimization you can do.

The cyris.io feedback form doesn't seem to be working, so that's my issue ;)

Other than that, thank you for something nifty that I'm sure to integrate into my setup :)

[ghost]

I'll backup that the feedback form (for Steamroller or Cyris's whole site) doesn't work ;0

[skibz]

that's some good feedback.

possible changes/new features:

• [ ] build a simple steam web api client library to facilitate the retrieval of player data, such as:
  • [ ] most played
  • [ ] recently played
  • [ ] daily deals
• [ ] replace the frontend js/css stuff with micro-libraries
• [ ] replace anything implementation-specific with an environment variable
• [ ] add contributing guidelines and dev workflow guide

[ghost]

WebAPI - I made one for SteamTray and would be happy to share ideas if you like. I use RedHat OpenShift's PAAS platform running Node.js and MongoDB cartridges - free and easy to setup. My API tracks Steam Review Scores, 'Early Access', Active Player Counts (like SteamCharts) and whether an appid is 'DLC' or "Tools" (not an easy thing to determine!)

Micro-libraries - deploying with node-webkit (nw.js) means the size of your code doesn't really matter - it's loading from local HDD after-all! nw.js's biggest performance issue is memory usage, the way it binds Node and Chromium is powerful but it's VERY reluctant to release memory and the size of the .js code isn't really a factor in that (my Heap is usually about 6Mb - my app uses 250Mb!!)

I've spent a long time (100s of hours over the last year) trying to find ways of making nw.js less memory abusive and right now I'd say it's not doable (tho there are changes coming in nw.js which might help at some polint)

One thing I did do is look at an nw.js competitor called atom-shell. atom-shell binds Node and Chromium differently - it opens WIndows as separate processes which, once closed, release all their resources - but it's nowhere near as mature and complete as nw.js - yet.

https://github.com/atom/atom-shell

My idea was to make a small Node-based process which offers a tasktray icon and only launch a 'Window' when the user wants to see their games - that way the footprint of your app is small when it's not in-use (but it's also releasing chunks of memory which can cause stutters - you can't win!!)

I decided not to switch to atom-shell because I have a lot of time invested in nw.js (I made an auto-updater and a few other utilities I'm not sure will work with atom-shell) If I were starting-afresh today tho, I'm not sure I wouldn't run with it because memory is the thing gamers will moan about most...

[skibz]

is your webapi accessible to the public?

my note on using micro-libraries was not for the purpose of optimisation. i'm simply of the opinion that using smaller and more focused frontend libraries helps with maintainability.

atom-shell sounds fantastic, as does your plan for the architecture of applications using it.

[skibz]

but, about optimisation and memory footprint:

i'd guess that most gamers have at least four gigabytes of ram. surely 200mb, while quite high for a simple steam game library overlay, wouldn't impact that badly?

the overhead of the chrome runtime really is quite bleak. :/

[CyrisXD]

Thanks for the feedback everyone. I've fixed the contact forms so they are working now. It seems my 2-step authentication messed with my smtp settings.

As for the high memory usage, it's interesting to see how its using way too much memory for some people and barely any for others. I have 250+ tiles loading and it's only using 15mb.

I did however have someone with the same-ish amount of games contact me and say it was using 2GB of ram. But after a restart the program jumped down to 20Mb. As far as I can tell the app uses way too much RAM on first load.

[ghost]

My WebAPI certainly could be made public - it changes fairly often tho (I'm tinkering!) and I can't guarantee it will always exist so you might want to roll your own at some point (there must be 1000s of us scraping Steam - 1 more won't hurt it!) :)

One of the issues with memory usage is that there are MANY ways of measuring it (even on Windows - let along factoring in OSX and Linux). Chromium isn't noted for being a 'light' application on any platform - nor is it noted for releasing memory it should really have long finished with tho - 15Mb would not have been it's entire footprint (what OS is that on?)

You're right that a modern gaming PC can easily spare a few 100s of Mbs and - indeed - it's better to allocate memory and keep it than to ask for it - release it - ask for more - release it. The latter leads to stutters and other performance issues you don't want to be responsible for - but people look at the headline memory usage and they judge you on that (and web-based apps have a reputation for being memory hungry)

It's also notable that the Steam Client has similar issues - it's Chromium (or at least webkit) based too and some people see tiny memory usage wheras others see Gbs of memory eaten - it's very odd.

End of the day, I'd rather my app used 'very little' when not in-use but I don't think that's realistic with nw.js at this point (it might be with atom-shell but I think that's maybe not quite ready for primetime)

[odensc]

If you make your API public I'll certainly take a look at it and maybe we'll fork it and use it for SteamRoller. I agree with you, there probably isn't much we can do about memory usage – but we should try to get it to stay under 250MB at most.

it might be with atom-shell but I think that's maybe not quite ready for primetime

atom-shell is pretty stable. It's what Atom uses (which is my current editor) and I haven't noticed much problems with it. I'll see if I can get SteamRoller running on atom-shell sometime and see if it makes any noticeable difference. EDIT: Just as a note, SteamRoller only takes up 19MB on my MacBook.

[ghost]

Problem with posting my API code is it contains stuff (a MongoDB access layer and a dynamic queue scheduler/load adjuster) that I wrote for a commercial client and which I can't really share.

I could remove/rewrite that bit - it's overkill for this task - but I hate the idea of having to retest it all!

On OSX, node-webkit uses "webhelper" processes so you need to include their memory footprint alongside the nw.app usage (in fact they use MOST of the memory IIRC?)

Here's SteamTray running on OSX (VM - I don't own a recent Mac so...)

https://dl.dropboxusercontent.com/u/1164739/nodeosxsteamtray.png

and here's node-webkit running "empty" (no app, just the empty window)

https://dl.dropboxusercontent.com/u/1164739/nodeosxempty.png

That's 50Mb used - about the same as an empty Windows build - not checked Linux but I'd be amazed if it were much different?

[odensc]

@shrewdlogarithm Ah, I was searching for "node" but meant to search for "nwjs" in my Activity Monitor. I get 89MB in total. That's still not much – anything <=100MB is fine IMO.

[TheDrDocter]

I have made a new style for the "save" button in the vhange user tool Gif: https://gfycat.com/CandidMatureChuckwalla

[TheDrDocter]

sorry, giffing tool speeds it up.

[odensc]

@TheDrDocter Alright, if you PR I'll take a look.

[TheDrDocter]

@thesbros Just did

[ghost]

I figured since I've spent FAR too much time chasing memory issues in SteamTray, I'd tinker with SteamRoller (0.4) for a bit - this one's an OSX screenshot

https://dl.dropboxusercontent.com/u/1164739/roller1osx.png

That's my 850-odd game collection SLOWLY scrolled up and down a couple of times - it seems to grow every time I do it (I guess it's finding and loading images I missed on earlier passes?)

Memory usage in Chromium does seem to vary between machines quite a bit - you'll see this in many apps (including Steam Client) - my theory is that it relates to the person's available memory/disk space and Chromium's obsession with hanging onto cached objects 'like it's life depended on it' (if you've ever tried to get it to refresh a CSS or JS file, you'll know what I mean!!)

Don't worry too much about that tho - because there's pretty much NOTHING you can do to stop it (assuming you're not leaking references to large arrays or objects into global, which you're probably not doing?)

[skibz]

(I guess it's finding and loading images I missed on earlier passes?)

quite likely. that's a lot of video games :P

[odensc]

@shrewdlogarithm It seems you're using node-webkit. I've been testing with nw.js and been getting lower mem usage. (or it could be because I don't have much games)

[ghost]

I've tested apps extensively with node-webkit 11.5, 11.6 and nw.js (which is node-webkit 12.0) - there is a slight reduction in memory after 11.5 (they fixed some stuff relating to the DevTools) but it's not enormous...

Note that nw.js/12.0 is NOT ready for production use yet, it's an alpha at best - 11.6 is what you should be shipping unless you want your users to be alpha testers for nw.js (which is fine!)

On 24 February 2015 at 18:37, Oden notifications@github.com wrote:

@shrewdlogarithm https://github.com/shrewdlogarithm It seems you're using node-webkit. I've been testing with nw.js and been getting lower mem usage. (or it could be because I don't have much games)

— Reply to this email directly or view it on GitHub https://github.com/CyrisXD/SteamRoller-Steam-Quick-Launcher/issues/5#issuecomment-75817366 .

[CyrisXD]

Just retested the compiled version on Windows, for about 250+ games this is my memory usage. Not as bad but still higher than I'd like it to be.

[ghost]

<100Mb for any app based on web tech (e.g. built on a browser) is actually pretty good - keeping it that low as people use the app, refresh their games etc. is quite hard tho.

My 'ideal' app would be a small NODE script which loads games from the net/local files and creates a tray icon to launch them. A window would only appear if you wanted to browse/edit the games available - you could also display your games via Chrome extensions or a RainMeter plugin or even on your phone/tablet (people use those as '2nd screens' etc. etc.)

Sadly I can't get that model to work right now - closing a Window doesn't free-up it's memory so you just end-up using MORE memory and not less.

I've used-up all the time I'm willing to spend on it for now - hopefully things will mature and I can do this at some point in the future...

p.s. if you want a good test account try "rroddbob" aka game developer Rob Fearon - he has over 2000 games on Steam!! There are people with more but not all have public profiles...

On 24 February 2015 at 20:34, CyrisXD notifications@github.com wrote:

Just retested the compiled version on Windows, for about 250+ games this is my memory usage. Not as bad but still higher than I'd like it to be. [image: 2015-02-25 09_31_41-reader] https://cloud.githubusercontent.com/assets/3248638/6358557/69e7be44-bcd1-11e4-81bc-aecf201cf7d8.png

— Reply to this email directly or view it on GitHub https://github.com/CyrisXD/SteamRoller-Steam-Quick-Launcher/issues/5#issuecomment-75839918 .

[odensc]

@shrewdlogarithm Couldn't atom-shell do something like that? It has the "background" process which is just a node script, that you could make a tray icon in and have it open a BrowserWindow when you click the tray. EDIT: I'm going to make a quick test app to see if this helps with memory.

[odensc]

Results with atom-shell: Window closed: 27.3 MB

Window open: 53.6 MB Note these are just with a hello world page with a bit of JS on it. I'll have to try with a ton of images.

[ghost]

atom-shell can do it in theory - however I'm concerned it's not quite ready for prime-time in other areas (packaging and updating apps in-particular)

I have a whole eye pointed at atom-shell and will follow it closely - I've raised some issues and questions already but I'm not ready to leave node-webkit just yet because it's the longest-standing, longest maintained app of it's type (it's only real weaknesses being memory and they're less developed on OSX) - people have even started to know what it is - there are games on Steam which use it!!!

I've learned, in the past, that you don't leave the older lifeboat for the shiny new one tho - sometimes the new one will sink first - sometimes experience > youth ;0

On 24 February 2015 at 21:11, Oden notifications@github.com wrote:

Results with atom-shell: Window closed: 26.4 MB https://camo.githubusercontent.com/5ecdeb096842c5e6b0afc868275148109206c44e/687474703a2f2f7075752e73682f67623763702f303035386465333138322e706e67 Window open: 53.6 MB https://camo.githubusercontent.com/9e28dbc3bf79502692361ec30f30e7170bea0bd8/687474703a2f2f7075752e73682f6762376e722f363932666336626631622e706e67

— Reply to this email directly or view it on GitHub https://github.com/CyrisXD/SteamRoller-Steam-Quick-Launcher/issues/5#issuecomment-75846921 .

[odensc]

@shrewdlogarithm I feel it would be fine for SteamRoller as we wouldn't need to use any of the stuff that isn't so developed yet (asar, etc). Maybe we should put out two versions (atom-shell and node-webkit) that people can try so we can see which one works better for SteamRoller.

EDIT: w/ 300 images atom-shell takes up 74.4 MB.

[ghost]

There are some significant differences in how some things work between node-webkit and atom-shell - if you choose to work with both you'll need to do a fair bit of 'designing around' that

In atom-shell, all your 'Node' stuff has to be done in the base Node Script (or via the remote package) and not in the Window (as you do with nw.js) - you'll end-up with 2 lots of source-code pretty quickly I reckon - but it's definately worth looking into because if you can say

"Yes it's a separate app, but if you minimize it, it only uses 25Mb of memory) - you have won something!!

On 24 February 2015 at 21:19, Oden notifications@github.com wrote:

@shrewdlogarithm https://github.com/shrewdlogarithm I feel it would be fine for SteamRoller as we wouldn't need to use any of the stuff that isn't so developed yet (asar, etc). Maybe we should put out two versions (atom-shell and node-webkit) that people can try so we can see which one works better for SteamRoller.

— Reply to this email directly or view it on GitHub https://github.com/CyrisXD/SteamRoller-Steam-Quick-Launcher/issues/5#issuecomment-75848392 .

[TheDrDocter]

This is my memory usage with the program. Seems to be ok. I do have a steam library of 120 games.

[odensc]

@TheDrDocter There's also a node-webkit helper you need to measure.

[TheDrDocter]

@thesbros Yep, now I see what you mean.

[TheDrDocter]

Well, I'm working on a "Quick Hide" button that is in the taskbar icon.

[odensc]

@TheDrDocter I don't think that'll do much, memory wise. Hiding the window doesn't free up any memory.

[TheDrDocter]

@thesbros I was thinking if we were able to create a button that unloads the program, but keeps the taskbar icon there so we can load it up again.

[skibz]

a nice addition could be to cache any of the images that are downloaded in /tmp or the user's home directory. in order to do this, we'd need to download the images using node and then point to them in the markup or frontend javascript.

with the cache as a fallback, we'd be free to unload any part of the program and not incur any further network overhead when the images need to be reloaded. we'd also be able to diff the cache with what the steam web api returns and only download images that are not yet present in the cache, if needed.

[TheDrDocter]

I think we should also watch/work on future updates on the program's source folders, it get kind of annoying whenever you open the program and see it have created another nw_###### folder.

[ghost]

The nw_##### folders are created because the ".nw" file is unzipped (usually into AppData/local/temp or it's equivalent) every time you run the app...

As for freeing memory - hiding the Window does very little, closing it doesn't do much more - reopening it will use MORE memory every time you do it - it's not the path to take with node-webkit/nw.js

On 25 February 2015 at 14:00, TheDrDocter notifications@github.com wrote:

I think we should also watch/work on future updates on the program's source folders, it get kind of annoying whenever you open the program and see it have created another nw_###### folder.

— Reply to this email directly or view it on GitHub https://github.com/CyrisXD/SteamRoller-Steam-Quick-Launcher/issues/5#issuecomment-75963679 .

[ghost]

and you don't need to bother 'caching' images manually - Chromium does it for you (in AppData/Local/YOURPROJECTNAME or it's equivalent on Linux/OSX)

On 25 February 2015 at 14:17, John Peat johnpeat@gmail.com wrote:

The nw_##### folders are created because the ".nw" file is unzipped (usually into AppData/local/temp or it's equivalent) every time you run the app...

As for freeing memory - hiding the Window does very little, closing it doesn't do much more - reopening it will use MORE memory every time you do it - it's not the path to take with node-webkit/nw.js

On 25 February 2015 at 14:00, TheDrDocter notifications@github.com wrote:

I think we should also watch/work on future updates on the program's source folders, it get kind of annoying whenever you open the program and see it have created another nw_###### folder.

— Reply to this email directly or view it on GitHub https://github.com/CyrisXD/SteamRoller-Steam-Quick-Launcher/issues/5#issuecomment-75963679 .

[skibz]

whatevs, just use the cached images breh.

[ghost]

He's already using them - it's a web browser, it does all that stuff whether you like it or not ;0

Remember that you have access to DevTools so you can see the state of Network/Cache transactions, get Heap Dumps, run a TimeLine - all the internals of the V8 engine can be checked (you can see what bits of your code aren't inlining properly) and so on...

You do get some stuff for the memory it consumes ;0

[skibz]

okay, given that - what can we really do, then, to improve the app as it stands? it seems clear that attempts at memory optimisation will be in vain.

perhaps we ought to add more app features to justify its memory usage?

[ghost]

That was my thinking - if you're gonna get people to install a whole new app, give-up the resources it needs etc - it has to do something other things don't do.

All I wanted was a tray menu which wasn't just my last couple of games - e.g. give me a choice what to show.

I've made "game cataloguing" software in the past tho - so I sort-of welded those together and probably got carried-away in the process - but that's software development!

On 25 February 2015 at 15:25, Ant Cosentino notifications@github.com wrote:

okay, given that - what can we really do, then, to improve the app as it stands? it seems clear that attempts at memory optimisation will be in vain.

perhaps we ought to add more app features to justify its memory usage?

— Reply to this email directly or view it on GitHub https://github.com/CyrisXD/SteamRoller-Steam-Quick-Launcher/issues/5#issuecomment-75979550 .

[TheDrDocter]

Has anyine else had the reset app problem? I can only seem to reset the application once, and after that the reset button is useless, I have to close the app to be able to reset again.

[TheDrDocter]

So, this has been quite a quiet project lately. What's everyone been up to?

[skibz]

hey man i have been busy with my job (see my commit log if you're interested)

[TheDrDocter]

So, I've just noticed this, but the progrma doesn't show any shared games. Would we ba able to add that in?

Also, when is v 0.5 to be released?