IRC logs for #openttd.dev on OFTC at 2013-07-06
⏴ go to previous day
06:42:05 *** Alberth has joined #openttd.dev
06:42:05 *** ChanServ sets mode: +v Alberth
08:28:19 *** ntoskrnl has joined #openttd.dev
10:46:12 *** frosch123 has joined #openttd.dev
10:46:12 *** ChanServ sets mode: +v frosch123
10:53:14 <frosch123> callgrind suggests to implement a cache for visual run layouts
11:32:54 <Terkhen> valgrind can do that? :O
11:36:36 * Alberth guesses that callgrind != valgrind
11:37:03 <frosch123> "callgrind" === "valgrind tool=callgrind"
11:37:43 <frosch123> and it tells me that viewing the advanced settigns screen in the intro gui, draws several 100 strings per second without doing anything :)
11:38:23 <frosch123> currently i check whether one can clip non-multiline strings earlier
11:39:07 <frosch123> but the ultimate trick should be caching the result of the layoutengine, which consumes 90% of cpu in text drawing
11:39:18 <frosch123> (in above testcase)
11:42:26 <Alberth> or don't draw the terrain below the windows :)
11:44:09 <Alberth> but that would fail for strings in the terrain
11:51:14 <frosch123> (never mind the debug printf :)
11:54:50 <Alberth> we draw that much outside the paint window? :o
11:55:51 <frosch123> currently i loaded a testgamer
11:56:15 <frosch123> there are two windows with moderate text (infrastructure count, and a news item)
11:56:26 <frosch123> and they cause about 256 stringdraws per second
11:56:36 <frosch123> there are 5 trains moving on the screen
11:56:44 <Alberth> readme display window?
11:57:25 <michi_cc> Infrastructure count should only redraw if there is a change. If not, I suspect a bug somewhere :)
11:57:36 <Alberth> oh, we build the full window for every small rectangle that we redarw of course
11:58:01 <frosch123> michi_cc: the screen is drawn in rectangles
11:58:10 <Alberth> michi_cc: also it the terrain behind it changing, eg a train passing
11:58:18 <frosch123> once a tiny bit of a window ends up in a rectangle to be drawn, the whole widget is drawn
11:58:38 <frosch123> anyway, opening a window with lots of text, like readme, advanced settings or so
11:58:48 <frosch123> skips around 2000 strings per second
11:59:21 <Alberth> minus the debug stuff :)
11:59:27 <michi_cc> But generally I think most text in windows should be handled/drawn by a WWT_TEXT and not ad-hoc all around (which does mean we need a matrix that can store widgets). WWT_TEXT can then cache the ParagraphLayout and all associated stuff for that string.
12:00:05 <frosch123> michi_cc: i thought about caching the visual runs
12:00:23 <frosch123> a checksum over a bunch of characters with the same colour and size
12:00:29 <frosch123> then a hash with the paragraph layout
12:00:38 <Alberth> frosch123: hmm, perhaps also check left/right?
12:00:56 <frosch123> changing all windows means a lot of work, and i have no idea whether it would even work for all windows, or improve anything
12:01:19 <frosch123> i only changed the function with draws single-line text
12:01:27 <Alberth> perhaps depending on the alignment?
12:01:44 <frosch123> that function only works for text which is has no linewraps etc
12:01:50 <frosch123> so i can check the y position
12:01:51 <Alberth> ie left of a string drawn left aligned
12:02:01 <frosch123> ok, left/right might work
12:02:20 <frosch123> i can check agains the truncation bounds
12:02:41 <frosch123> but i guess if that triggers the widget clipping would have triggered anyway
12:02:46 <Alberth> not sure whether it would pay sufficient
12:03:13 <Alberth> most windows don't have much stuff next to each other
13:04:04 <frosch123> yay, the most expensive function does not depend on "maxw"
13:04:32 *** Zuu has joined #openttd.dev
14:47:17 <frosch123> i implemented the cache thingie
14:47:31 <frosch123> i just started ottd, opened the advanced settings
14:47:50 <frosch123> and now i already have 80000 cache acccesses, while there were only 519 layout computations in total
14:48:03 <frosch123> so almost infinite speedup
14:48:43 <frosch123> hmm, it's buggy though :p
14:52:07 *** ntoskrnl has joined #openttd.dev
15:08:45 <frosch123> well, since the 519 stayed constant, while the 80000 was constantly growing, you can get any number
15:08:50 <frosch123> i did not lmit the cachesize yet
15:11:50 <Alberth> 520 strings should be enough :p
15:12:25 <frosch123> well, then you run out of date strings after 520 days at least :p
15:13:08 <Alberth> nice short game then :)
15:13:58 <frosch123> if you draw the year with a different colour, it will last for 154 years
15:14:29 <Alberth> oh, that's enough, my games never last more than 80 years
15:15:08 <frosch123> we speeded up drawing by drawing the year with a different colour
15:15:13 <Alberth> maybe we should not draw the year, it's not important any way
15:15:29 <frosch123> would also solve daylength
15:16:38 * Alberth afk, looking for some dinner
16:14:50 <frosch123> luckily icu is open source, so you can look at the source when the documentation is incomprehensive :)
17:53:50 <Alberth> FontSize fontsize; TextColour cur_colour, prev_colour; could use some doxygenation
17:55:38 <Alberth> 10 shouldn't you use the new method as well? it looks a bit weird now
17:56:33 <frosch123> it implements a icu funtion in our icu replacement
17:59:31 <frosch123> but yeah, moving it to 40 saves commits
18:02:42 <Alberth> 40 also misses doxygen stuff
18:03:48 <Alberth> src/gfx_layout.cpp + } line 488 in 40 is weird, no dedent
18:06:00 <Alberth> ugh, I am wondering why you don't implement FontState() as { this(FS_END, TC_INVALID, TC_INVALID); } ;p
18:06:16 <frosch123> what language is that? :p
18:06:22 <Alberth> java does weird things to your mind :)
18:06:38 <frosch123> ah, yeah, java has that
18:07:22 <frosch123> hmm, never tried a core file from a program that ran in valgrind
18:09:28 <Alberth> except for 99, seems fine
18:17:18 <frosch123> hmm, i quite mismerged somewhen inbetween
18:26:36 <frosch123> no, 40 had bugs i fixed before
18:26:48 <frosch123> but also a new one, so it is fine :)
18:30:33 <Alberth> fixing the same bugs over and over again gets boring :)
18:35:03 <frosch123> hmm, is it troublesome if valgrind reports strlen to read 4 bytes in strings with length 0?
18:37:08 *** Supercheese has joined #openttd.dev
18:48:53 <frosch123> i guess the strlen in some super efficient implementation which reads stuff in blocks of 4 bytes
18:49:02 <frosch123> assumeing that everything is aligned anyway
18:49:32 <frosch123> valgrind sayd it read 4 bytes in a block of 1 allocated bytes
18:49:49 <Alberth> read is mostly harmless I guess
18:50:45 <Alberth> and it probably did that for ages already :)
18:51:24 <frosch123> it's not our implementation :)
18:51:34 <frosch123> at least i hope that we did not have to implement a custom strlen :p
18:51:47 <Alberth> even better, then we can blame someone instead :)
18:55:09 <frosch123> oh, just noticed i couldn't count, i have two 20 :p
19:12:58 <Alberth> 30 plays hide and seek :)
20:51:56 *** Alberth has left #openttd.dev
21:22:16 *** Zuu has joined #openttd.dev
continue to next day ⏵