--- Log for 01.11.120  Server: weber.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 3 days and 21 hours ago

00.15.22 Quit    [7] (Disconnected by services)
00.15.28 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
00.41.39 ***     Saving seen data "./dancer.seen"
01.08.44 Quit    mendel_munkis_ (Remote host closed the connection)
01.10.07 Join    mendelmunkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net)
01.12.21 Quit    massiveH (Quit: Leaving)
01.41.42 ***     Saving seen data "./dancer.seen"
03.03.21 Join    _bilgus_ [0] (~bilgus@65.186.35.190)
03.04.25 Quit    _bilgus__ (Ping timeout: 264 seconds)
03.41.46 ***     Saving seen data "./dancer.seen"
03.47.01 Join    lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
04.17.34 Join    johnb3 [0] (~johnb2@p5b3aff9d.dip0.t-ipconnect.de)
04.39.38 Quit    prof_wolfff (Ping timeout: 264 seconds)
05.36.08 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
05.41.50 ***     Saving seen data "./dancer.seen"
05.56.57 Join    MrZeus [0] (~MrZeus@185.195.232.149)
07.24.26 #       <fs-bluebot_> Build Server message: New build round started. Revision f9ba96c, 293 builds, 8 clients.
07.39.00 #       <fs-bluebot_> Build Server message: Build round completed after 874 seconds.
07.39.04 #       <fs-bluebot_> Build Server message: Revision f9ba96c result: All green
07.41.53 ***     No seen item changed, no save performed.
07.56.02 Join    prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net)
08.15.34 Quit    pamaury (Ping timeout: 246 seconds)
08.17.38 Join    livvy [0] (~livvy@gateway/tor-sasl/livvy)
09.28.44 Quit    prof_wolfff (Ping timeout: 258 seconds)
09.35.03 Part    edhelas
09.35.44 Join    edhelas [0] (9d94237298@2a01:7c8:aab8:6b9:5054:ff:fec9:fd84)
09.41.55 ***     Saving seen data "./dancer.seen"
10.20.18 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
10.57.12 Quit    johnb3 (Ping timeout: 272 seconds)
11.19.38 #       <_bilgus_> lebellium, do you have a physical OndaVx?
11.20.05 #       <lebellium> no
11.21.08 #       <_bilgus_> well here is the probalem even at head I can not reproduce the issues I see in the Onda sim on the other physical player I have
11.21.20 #       <_bilgus_> maybe I should try another sim
11.21.43 #       <_bilgus_> this is with the failsafe theme so I doubt its a theme thing
11.24.40 #       <_bilgus_> either that or maybe touch screen targets in general but the issue I see is that in failsafe the text is drawn and then cleared and never refreshed again (even with the dirty vp stuff disabled)
11.26.01 #       <_bilgus_> I try to force redraw anywhere in the stack above it still doesnt redraw but if I go to the place where text is drawn and set it update=true it works fine but redraws too much then
11.26.35 #       <_bilgus_> someone is removing my redraw but I can't seem to find where
11.27.18 #       <lebellium> we don't have many touch screen sims
11.27.35 #       <lebellium> If we had a YP-R1 sim, I wouldn't use the Onda VX
11.27.48 #       <lebellium> I'm wondering is anyone is still using this device
11.28.36 #       <_bilgus_> I think I might just hack it so the Onda forces redraw
11.29.04 #       <_bilgus_> the issue is reduced battery life but at least it redraws properly
11.41.26 Join    prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net)
11.41.57 ***     Saving seen data "./dancer.seen"
11.43.40 #       <_bilgus_> lebellium, do you know how to check out a branch prior to a commit its just checkout Commit-ID right?
11.46.05 #       <_bilgus_> anyway I assume thats right anyway the issue was existing (at least in the sim)
11.46.39 #       <_bilgus_> coding around it and I'll revisit if we get something concrete
11.46.40 #       <speachy> lebellium: if you could take hi-res photo of the YP-R1 I can hack a sim target into being around it.
11.48.08 #       <lebellium> _bilgus_: I don't know much about git. I always need the wiki page https://www.rockbox.org/wiki/UsingGit#How_do_I_check_out_the_revision_previous_to_current_63
11.48.31 #       <_bilgus_> I checked the source files I did it right
11.49.47 #       <_bilgus_> its an existing issue
11.50.56 #       <lebellium> speachy: thanks. I'll try with daylight
11.51.24 Quit    Acou_Bass (Ping timeout: 240 seconds)
12.02.19 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
12.37.57 Join    johnb3 [0] (~johnb2@p5b3aff9d.dip0.t-ipconnect.de)
12.40.26 Quit    Acou_Bass (Ping timeout: 272 seconds)
12.43.45 #       <fs-bluebot_> Build Server message: New build round started. Revision 0c99a3f, 293 builds, 8 clients.
12.44.02 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
12.44.23 #       <_bilgus_> lebellium, The other issues with the onda sim are fixed I in this patch
12.45.05 #       <_bilgus_> I had the FS issue fixed sometime in the process of trying to fix this bug but I'll have to revisit that later
12.48.37 Nick    mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net)
12.50.55 #       <mendel_munkis> _bilgus_: how is a function call faster than an if?
12.57.19 #       <fs-bluebot_> Build Server message: Build round completed after 813 seconds.
12.57.23 #       <fs-bluebot_> Build Server message: Revision 0c99a3f result: All green
13.07.46 Quit    johnb3 (Quit: Nettalk6 - www.ntalk.de)
13.08.01 #       <_bilgus_> I don't know that I could say it is without benchmarks and a caveat of depends on arch and compiler but it gets rid of a branch
13.08.39 #       <_bilgus_> the code no longer has to go two ways to exit it just calls the function and returns
13.10.11 #       <_bilgus_> now if we start talking about multiple ifs then the cost is amortized and its just better and better we can do processing outside the hot path
13.12.43 #       <_bilgus_> did you find the fn ptr code to be much slower than the original?
13.19.31 #       <mendel_munkis> I haven't actually benchmarked it I was just thinking about the fact that a function call requires stack overhead.
13.22.53 #       <_bilgus_> tbh I'd expect the compiler to inline the thing in the standard case
13.23.58 #       <mendel_munkis> in which case it becomes an if again just with an added function call. (if I understand inlining correctly)
13.24.02 #       <_bilgus_> once you add other conditionals though all bets are off
13.24.18 #       <_bilgus_> no function call if inlined
13.24.46 #       <mendel_munkis> in the non standard case. unless you're say it would inline both?
13.25.02 #       <_bilgus_> ah
13.25.39 #       <_bilgus_> don't know tbh depends on the compiler
13.26.07 #       <_bilgus_> it might inline both but that depends on so many vars
13.26.37 #       <speachy> we're using -Os (except the codecs) so the compiler will generally prefer strategies that produces the smallest code.
13.26.48 #       <_bilgus_> &^
13.27.26 #       <speachy> I think GCC describes it as "enable everything from -O2 except where it results in a larger binary size"
13.28.07 #       <_bilgus_> we can worry about this but really its already at 75 fps pretty good
13.31.22 #       <_bilgus_> now the 30% slow drawing routines OTOH
13.31.37 Quit    emacsomancer (Read error: Connection reset by peer)
13.32.07 #       <_bilgus_> I'm gonna try for 10% hopefully the end up 15% slower
13.33.55 #       <mendel_munkis> I got identical speeds with both builds. (according to test_fps) but I prefer patchset 2 if there is no optimization difference
13.34.38 #       <mendel_munkis> also what kind of glitches were you seeing and where they only with screen_flip enabled?
13.36.38 #       <_bilgus_> yes only when flipped
13.37.09 #       <_bilgus_> it was like tearing with a white flash
13.37.49 #       <_bilgus_> its your patch I prefer 3 but tbh IDC enough to argue with you or i'd do it myself :P
13.38.29 #       <_bilgus_> but i'll be back later I have to go put a starter on my car I'm tired of driving the backup it kills me in gas
13.38.44 #       <speachy> _bilgus_: good luck.
13.38.53 #       * speachy still reeks of gasoline
13.39.22 #       <_bilgus_> that was last week when I fixed the backup because I anticipated this starter issue
13.39.42 #       <_bilgus_> it needed a new filler neck
13.39.43 Quit    livvy (Ping timeout: 240 seconds)
13.41.58 ***     Saving seen data "./dancer.seen"
13.43.01 Join    emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
13.50.57 #       <mendel_munkis> nothing. if you're using cabbie I can't think of anything else that would cause it.
14.36.20 Quit    pamaury (Ping timeout: 272 seconds)
15.18.03 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
15.42.01 ***     Saving seen data "./dancer.seen"
16.08.25 Quit    Acou_Bass (Ping timeout: 240 seconds)
16.10.35 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
16.15.25 Quit    Acou_Bass (Ping timeout: 240 seconds)
16.39.35 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
17.12.22 Quit    lebellium (Quit: Leaving)
17.42.03 ***     Saving seen data "./dancer.seen"
18.00.04 Quit    mendel_munkis (Remote host closed the connection)
18.00.18 Join    mendel_munkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net)
18.18.15 Quit    Acou_Bass (Ping timeout: 260 seconds)
18.21.42 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
18.44.05 Quit    Acou_Bass (Ping timeout: 240 seconds)
18.47.53 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
19.09.12 Quit    pamaury (Quit: this->disconnect())
19.36.31 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
19.37.50 Join    fs-bluebot [0] (~fs-bluebo@55d44115.access.ecotel.net)
19.39.45 Quit    fs-bluebot_ (Ping timeout: 240 seconds)
19.39.49 Quit    bluebrother^ (Ping timeout: 264 seconds)
19.42.05 ***     Saving seen data "./dancer.seen"
20.06.18 Join    mendel_munkis_ [0] (~mendelmun@ool-435680b7.dyn.optonline.net)
20.08.45 Quit    mendel_munkis (Ping timeout: 240 seconds)
20.38.49 Quit    MrZeus (Ping timeout: 256 seconds)
20.55.31 Quit    speachy (Ping timeout: 260 seconds)
21.03.09 #       <_bilgus_> mendel testing I grabbed the patchset from gerrit and it is bouncing around when flipped just scrolled the menu to the top and it bounces I'll try again after rebase
21.14.41 #       <_bilgus_> mendel_munkis_, OK same deal at head after flipping, in main menu hold the up key and watch after it hits the stop it keeps bouncing around
21.15.45 #       <_bilgus_> test_viewports plugin the screen tears in lines 1 - 11 pixel wide horizontal bands that glitch across the screen with equal spacing
21.15.57 #       <_bilgus_> the scrolling text doesn't work either
21.17.11 #       <_bilgus_> right side up main menu is stable test viewports works fine and scrolling text is working
21.17.23 Nick    mendel_munkis_ is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net)
21.17.31 #       <mendel_munkis> give me a second to rebase on head.
21.17.39 Join    speachy [0] (~speachy@209.2.65.77)
21.17.54 #       <_bilgus_> its the same there just test_viewports has a stack ovfl :)
21.19.25 #       <braewoods> _bilgus_: i think i'm going to rewrite iriver_flash and submit it when I'm done fully testing it... i'll need to retain compatibility with some old stuff but beyond that...
21.20.01 #       <_bilgus_> braewoods, patches welcome :)
21.20.20 #       <braewoods> i feel like i keep patching old assumptions and it feels like i need to start from scratch and just use the old one as reference
21.20.33 #       <braewoods> just to wrap my head around the whole logic
21.23.29 #       <mendel_munkis> A. I can't reproduce on head B. that sounds identical to patchless behavior.
21.27.29 #       <_bilgus_> ok lets rebase the commit on gerrit ands I'll try pulling it again
21.28.14 #       <_bilgus_> well actually its not too deep I'll just verify its there
21.29.25 #       <_bilgus_> yes 3 is there I'll try copy pasta 2
21.31.52 #       <mendel_munkis> does if else order matter for optimization?
21.32.36 #       <_bilgus_> sometimes but I use LIKELY or UNLIKELY to the same effect
21.33.14 #       <_bilgus_> just don't use it wrong
21.34.28 #       <_bilgus_> gonna be a minute I nuked the build dir to be sure
21.36.52 #       <_bilgus_> mendel as a general rule of thumb unless you know its a bottleneck no real point in bothering
21.37.36 #       <mendel_munkis> Well you were concerned about the inefficiency of using an if.
21.38.40 #       <_bilgus_> and .5 fps is not much
21.40.15 #       <_bilgus_> also I'm not sure what the most likely path is amongst fuze+ users
21.40.34 Quit    Acou_Bass (Ping timeout: 256 seconds)
21.40.41 #       <_bilgus_> the player is begging to be upside down its even weighted towards that end
21.42.07 ***     Saving seen data "./dancer.seen"
21.42.12 #       <mendel_munkis> I find that using it upside down tends to result in my thumb covering half the screen.
21.46.18 #       <_bilgus_> same deal with patchset 2
21.46.27 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
21.47.38 #       <mendel_munkis> whats the version number?
21.47.54 #       <_bilgus_> of?
21.48.03 #       <mendel_munkis> rockbox
21.48.32 #       <_bilgus_> a7ac39511dM-201102
21.48.42 #       <_bilgus_> send me your version
21.48.51 #       <mendel_munkis> the zip?
21.48.54 #       <_bilgus_> yes
21.49.18 #       <_bilgus_> lets remove this first
21.49.35 #       <_bilgus_> then we can start questioning device differences
21.50.51 #       <mendel_munkis> can you send me your cfg while we are at it?
21.51.08 #       <mendel_munkis> it's uploading now
21.51.18 #       <_bilgus_> in debug we have hw info>target it says lcd kind ili9325
21.51.43 #       <_bilgus_> my config for rb? its a clean install too
21.52.00 #       <_bilgus_> I presume it might have the lcd flip maybe?
21.52.43 #       <mendel_munkis> ok it's not a config difference.
21.53.04 #       <mendel_munkis> but seeing as I have a st7781 that's probably the cause
21.53.12 #       <_bilgus_> I wanted to remove all vars I nuked everything
21.53.14 #       <mendel_munkis> *st7783
21.53.52 #       <mendel_munkis> so I need to update to check lcd type.
21.53.54 #       <_bilgus_> ah there we go ok so mine either needs special handling or is a bad implementation
21.54.10 #       <mendel_munkis> nope mine is the bad implementation that needs special handling.
21.54.26 #       <mendel_munkis> the patch was to introduce the special handling.
21.54.28 #       <_bilgus_> pretty sure mine glitched at head too
21.54.44 #       <_bilgus_> let me double check that
21.55.22 #       <mendel_munkis> don't tell me they have different bad handling
21.56.37 #       <_bilgus_> ah also it would not be a compile time constant either :(
21.58.17 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
21.59.24 #       <mendel_munkis> The data sheet has the same quote about locations except it  uses GRAM not DRAM
21.59.38 #       <_bilgus_> ok so your patch improved the part in the main menu BUT
22.00.10 #       <_bilgus_> the scrolling lines work in test viewport no glitches they are just misplaced
22.00.33 #       <_bilgus_> so you know which part did work
22.00.44 #       <_bilgus_> and the register part did not
22.01.02 #       <mendel_munkis> I have three Fuze+s and they are all st7783 so I have no way to test.
22.01.55 #       <mendel_munkis> also I don't see why moving a chunk of video memory should cause scrolling glitches but I will see if I can figure it out.
22.02.09 #       <_bilgus_> ok so the viewport part leqave it for everyone and the register changes -ifdef- nope not ifdef because its not a compile time constant
22.02.30 #       <mendel_munkis> the registers are the same according to the datasheets.
22.02.47 #       <_bilgus_> hopefully you can do that stuff in the menu and not in the draw routine
22.03.16 #       <_bilgus_> I'm saying my device works better without the register changes you made
22.03.49 #       <mendel_munkis> so the datasheet is wrong.
22.04.53 #       <mendel_munkis> also what viewport part?
22.05.07 #       <_bilgus_> OH I thought you also sent another set of commands to the lcd for flip but it looks like you just added height-y
22.05.14 #       <mendel_munkis> I didn't touch the viewport
22.05.22 #       <_bilgus_> that is the vp
22.05.32 #       <_bilgus_> its just the default one
22.05.50 #       <mendel_munkis> ah. i was thinking of it as the registers containing the rectangle to be updated.
22.06.29 #       <mendel_munkis> because technically it doesn't have  to be a viewport.
22.06.48 #       <_bilgus_> no but it helps to think of it when it comes to transforms
22.07.05 #       <_bilgus_> or windows if you prefer
22.07.09 #       <_bilgus_> canvas
22.07.22 #       <mendel_munkis> fair enough.  I just thought that the rockbox viewport os something else and didn't want to confuse them.
22.07.48 #       <_bilgus_> its all bitmaps
22.09.06 #       <mendel_munkis> so register 21 is what was causing problems?
22.17.32 #       <_bilgus_> ? no idea
22.18.36 #       <_bilgus_> changing it back to y but leaving the other two makes the scrolling lines show right but its still glitchy
22.19.02 #       <_bilgus_> and it is off like 6 lines everywhere else
22.19.19 #       <_bilgus_> its odd and makes me want to do it in software
22.19.27 #       <mendel_munkis> that makes sense. It's why I set it in the first place
22.20.15 #       <_bilgus_> it just seems like too much effort for one target when they can just all get it
22.20.37 #       <mendel_munkis> butdoing it in software is so much slower
22.21.20 #       <_bilgus_> I doubt reverse memset is much slower than forward memset
22.21.42 #       <braewoods> _bilgus_: meaning where they start from is different?
22.23.40 #       <_bilgus_> yes one goes 0- 1228000 and the other goes 1228000 - 0
22.25.17 #       <mendel_munkis> _bilgus_ what happens if you add 128 to reg_3_val?
22.25.25 #       <mendel_munkis> that's ili specific
22.26.42 #       <_bilgus_> where should I add it? its checking &0x20 do I need to add it there too?
22.27.49 #       <_bilgus_> 0x1080?
22.28.06 #       <mendel_munkis> no in lcd_set_flip instead of 0x1000 use 0x1080
22.28.08 #       <mendel_munkis> yes
22.29.33 #       <mendel_munkis> although I need to think for a few minutes if that would be with the old or new value of register 21.
22.30.35 #       <_bilgus_> its almost perfect and I put it back before I changed it
22.30.42 Quit    Acou_Bass (Ping timeout: 272 seconds)
22.30.53 #       <_bilgus_> so h-y for reg 21
22.31.30 #       <mendel_munkis> try it with just y.
22.31.33 #       <_bilgus_> it has just the slightest flutter up and down in the menus and no glitch in the plugin
22.31.36 #       <_bilgus_> ok
22.32.29 Quit    Stanley00 (Read error: Connection reset by peer)
22.32.38 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
22.33.13 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
22.34.37 #       <_bilgus_> menu worse
22.34.46 #       <_bilgus_> vp_test no change
22.35.13 #       <_bilgus_> I'd call it good enough to say you've got it
22.36.04 #       <mendel_munkis> ok now I have to make sure the that bit flag won't blow up the st7783
22.36.32 #       <_bilgus_> oh itd be nice if they go together I figured you'd have to split on them
22.37.07 #       <mendel_munkis> the data sheet just has it zerod out. either it needs to be zero or it doesn't have much effect.
22.38.11 #       <_bilgus_> so in your math LCD_HEIGHT-(y+h-1));
22.38.33 #       <_bilgus_> that paren is superfluous
22.39.46 #       <mendel_munkis> ok. I never remember the order of operations so I usually am very liberal with parenthesis on the basis that it cant hurt.
22.39.57 #       <_bilgus_> instead do int y_f = height - y and use it in place so the compiler can optimize
22.40.32 #       <_bilgus_> right now unless its smart those are at best 2 and at worst 3 calcs
22.40.38 #       <mendel_munkis> y_f for y floor?
22.40.50 #       <_bilgus_> y_f as in flipped lol
22.41.04 #       <mendel_munkis> wow
22.41.57 #       <_bilgus_> or yr for y reflected?
22.57.13 #       <mendel_munkis> I made a few minor changes to make it cleaner and fix a small artifact. (and managed to screw up committing them) can you test patchset 9?
22.59.40 #       <_bilgus_> is it the latest?
22.59.58 #       <_bilgus_> yep
23.03.11 #       <_bilgus_> run oscilloscope in flipped mode
23.03.48 #       <_bilgus_> get a wall of red on first run through?
23.05.17 #       <mendel_munkis> yup.
23.05.42 #       <_bilgus_> so off by 1 maybe?
23.06.13 #       <mendel_munkis> how would an off by one cause that?
23.06.33 #       <_bilgus_> grabbing the wrong line?
23.07.27 #       <mendel_munkis> so I fixedd one off by one and caused another.
23.07.45 #       <_bilgus_> off by 1/2?
23.08.39 #       <_bilgus_> just thinking of how oscope works that line is stationary its the copying code that moves it
23.09.04 #       <_bilgus_> but it could be something weird about the lcd too
23.09.37 #       <_bilgus_> hell if I know you are the one who figured it out :)
23.14.13 Quit    TheSeven (Disconnected by services)
23.14.23 Join    [7] [0] (~quassel@rockbox/developer/TheSeven)
23.15.33 #       <mendel_munkis> I can;t figure out where it gets any red in the first place.
23.17.01 #       <mendel_munkis> also the rectangles it's updating seem weird.
23.18.32 Quit    _bilgus_ (Remote host closed the connection)
23.22.14 Join    _bilgus [0] (~bilgus@65.186.35.190)
23.23.08 #       <_bilgus> mendel rest assured it is weird
23.23.38 #       <_bilgus> but it follows the implementation to the T it is a very good test
23.24.00 #       <_bilgus> any little thing off breaks it in horrible ways
23.24.13 #       <mendel_munkis> ok. oscilloscope was  always weird to me. when I first realized you can set it wrap it changed everything.
23.24.39 #       <_bilgus> I was neck deep in there for a week
23.42.09 ***     Saving seen data "./dancer.seen"
23.43.37 Quit    Stanley00 (Read error: Connection reset by peer)
23.44.06 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
23.46.22 #       <mendel_munkis> the red bar is also at head
23.46.59 #       <mendel_munkis> s/bar/wall/
23.48.18 #       <_bilgus> hmm then carry on
23.48.56 #       <_bilgus> not making it worse at least
23.49.35 #       <_bilgus> there will be more bugs appearing with the framebuffer stuff too
23.50.52 #       <mendel_munkis> I haven't noticed anything blowing up because of the register, and I cant think offhand of how these registers cause it (although I did noarrow it down to line 980 not saving the old state)
23.51.54 #       <mendel_munkis> I think if the only issue you noticed was the oscilloscope it's committable.
23.52.08 #       <mendel_munkis> di the last patchset help ith the menu flutter?
23.54.57 #       <_bilgus> #9?
23.55.06 #       <mendel_munkis> yes
23.55.56 #       <_bilgus> idk maybe the magnitude is less
23.58.30 #       <mendel_munkis> I think it's probably an off by one. but that's one I cant test.