freenode/#shirakumo - IRC Chatlog
Search
10:06:56
Shinmera
I have a constraint layout with one element being set to constrain to have a 80un gap to the border, but when the scaling factor changes (from a resize or whatever), it at some point starts going out the border.
11:44:39
scymtym
Shinmera: do you have any benchmarks or numbers regarding the amount of speedup in gf dispatch you are looking for?
12:42:55
ShinmerAgain
So having them be faster at all should already show noticeable performance changes
12:46:57
ShinmerAgain
I could provide some measurement data of the game for you if there's anything that would help you
12:49:20
scymtym
i just have no idea what you expect. whether it is "cut dispatch time in half" or "get within X % of non-generic function calls", for example
12:50:32
scymtym
sprof output wouldn't hurt although i'm not sure i can reliably extract the dispatch overhead from that
12:51:53
scymtym
a benchmark. but i realize that anything besides running the actual game is both too much effort and also probably of limited usefulness
12:54:19
scymtym
when your framerate is fixed, execution times of subsystems for a single frame, maybe
12:54:25
ShinmerAgain
I could look through the source and tell you what kinds of gfs I'm using and the numbers of classes and methods involved, I suppose
12:55:03
scymtym
in all honestly, i should probably work on completeness and conformance before asking you to provide anything
12:57:04
ShinmerAgain
There's two big gfs that encompass the whole procrss. One called "handle" to react to events, and one called "render" to invoke gl stuff.
12:57:44
ShinmerAgain
handle is called at fixed timesteps, and render is usuall free, meaning variable timesteps
12:58:18
ShinmerAgain
render is probably also not so useful to instrument due to gl calls stalling a lot and being unredictable
13:05:59
ShinmerAgain
handle is a 2-arg gf with almost all methods being specialised on both. there's also quite a few before/after methods, but not that many around.