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