[Feature] Multiple In-Game overlays about gosumemory HOT 4 OPEN

Ok, so I had a quick look at https://www.github.com/l3lackShark/config. I found, that the way, that I laid out here will not work. Instead I propose, to just add a Number, after each overlay* property, like follows:

overlayURL0 = http://localhost:24050/Simplistic
overlayWidth0 = 650
overlayHeight0 = 150
overlayOffsetX0 =0
overlayOffsetY0 =5
overlayScale0 =10

Of course, this requires, that there is a overlay entry, from 0-n, because otherwise it will end up getting messy.
Everything would be easier, if the config was in json/xml/yml. Then we could just have this be an Array.

Or how about overlay[n].{URL,Width,Height,OffsetX,OffsetY,Scale} (Also possibly keep #62 in mind?)
This would require more logic on [ and . , or one could just implement a comment, via any char combo (# and ; come to mind) and prefix the [Header] Sections with comments.

from gosumemory.

This will require a lot of changes on the c++ side of things. I'm not even sure if it's a good idea to have two instances of the browser (possible huge performance drop). Will check if it's reliable at some point.

from gosumemory.

I am talking about potentially a lot more instances, than two. I mean, like a scaleable solution.

• Why is it so expensive to run a browser?
• Is it the way, that javascript get's the updates?
• Is it, that there is just too much data flowing from gosumemory to the browser via websockets?

1. Maybe one could just send changes, after an initial sync, with a new ws client? Like an initial "Hello, I'm a new client!", with a full response. Is there a better way to implement real time sync? What is expensive about the browser? or is it just the way, that the browser works?
2. Or maybe we could l3lackShark/static#21 simplify the individual modules to a point, where all one has to do is add one line of js code, to add a overlay? Something like:

var socket = undefined;
var modulesJsCallbacks = [];
function getdatastuff(callback){
    if (socket) socket=initws()
    switch(wseventtype){
        case "resize":
            handleRezise()
            break
        case "move":
           handleMove()
           break;
        case "partialTransfer":
           handlePartialTransfer(callback)
           break;
        case "fullTransfer":
           handleFullTransfer(callback)
           break;
        case "addModule":
           handleLoadModule()
           break;
        case "rmModule":
           handleUnloadModule()
           break;
    }
}
getdatastuff((data)=>{
    modulesJsCallbacks.forEach((i)=>i(data))
}

Then one could containerize (div elements?) the individual counters. The individual counters could still be moved via CSS, but the positioning will have to happen as a websocket event. The Module offset could still be stored via the config, but the first thing, that would have to happen is a move and resize event for all loaded modules.
The div's for the individual modules would then be identified, by an identifier. For starters we could either use the Module name, which would restrict the possible modules to one per module, or we could use a numeric id.
The upsides would be a solution, which could accomidate all Modules in a single browser instance.

from gosumemory.

• Why is it so expensive to run a browser?

The biggest issue is the legacy opengl calls we use to draw the overlay. The more pixels you have to push the worsen it becomes. This is probably fine with a couple of small overlays, but then again, c++ side of things also need a huge change to add support for that. The ideal solution would be switching to PBOs.

from gosumemory.